IDE first vs Compiler first, your opinion, just pie-in-the-sky stuff.

[Elroy]

Ok, let's overlook the question of whether or not any of this is possible. Let's assume (just for the sake of argument) that we've got the resources to start development of a VB6 syntax compatible language, and our primary objective is to get to a native 64-bit language.

Furthermore, our resources aren't unlimited so we have to make a choice. Therefore, this poll...

It's been suggested that this is a "fracture", but personally I don't think it's much of one.

(p.s., I know I may have biased the answers by putting in the 64-bit requirement, but any VB6.5 effort that doesn't address that is totally off of my radar.)

[dilettante]

Unless you think an IDE is just a text editor this makes little sense.

The VB6 "IDE" does a heck of a lot more than that as well as being pass 1 of the compiler and a debugger too. That's without even beginning to look at what designers do in VB6 which includes "compilation" of a sort as well though mainly for declarative things like UI layout and beyond (e.g. the DataEnvironment).

[Elroy]

Well Dil, like I said in another thread, I'd be happy with the memory constraints of 32-bit, even for a 64-bit application. Therefore, if I could test in our existing VB6 IDE, and just get a compiled 64-bit executable ... personally, I'd be very happy. Heck, just getting a compiled VB6-syntax "Hello World" app compiled as 64-bit would make me giddy.

[wqweto]

Someday you have to make a tutorial on "How to make Polls on most vBulletin boards" or similarly confusing excuse of a forum software. . .

cheers,
</wqw>

[dilettante]

I've yet to see a cogent argument for 64-bit executeables.

I could see some argument for the Sad Sack trying to support MS Office applications by providing DLLs, but I'm not aware of any obvious way to make them dual-bitness anyway.

Is there even a 64-bit Visual Studio yet?

Remember, we wouldn't even have 64-bit desktop Windows if it wasn't for pressure from the hardware vendors to get you to buy more stuff. 64-bit makes some sense for servers but far less on a client system. Sadly that genie is already out of the bottle, like the hardware peddlers who pushed gratuitously high-res monitors, saddling us with the High DPI issues.

A 64-bit desktop OS is just a big red clown nose. Jangling keys that attract the simple-minded, you know, like naive MS Office users who want to snap their suspenders and feel like a big man. They probably buy big pickup trucks hoping to compensate a little bit that way too.

[Elroy]

Dil,

I don't entirely disagree. However, having a 64-bit OS does make some sense (but that's really an aside). With our 64-bit OSs, and if we were to use LAA, we can get a full 4GB. Also, if we're one of those people who simultaneously runs 47 applications all at once (or run Chrome with 83 tabs open), having a system chocked full of memory does help.

But a 64-bit OS is different from a 64-bit application. I suppose there are just a couple of things that push me into wanting a 64-bit compiled program: 1) I fear that I may someday run into a desktop computer without WoW installed on it, and 2) it's just a marketing/perception thing. When users find out it's only available in 32-bit, they look down their nose at you for a moment. I know that last one has nothing to do with performance, but it's still a fact of life in 2019.

----------

And, if getting to 64-bit isn't our top priority for VB6.5, I'm not sure what is:

• Fix a few IDE and/or compiler bugs? Not a biggie for me.
• Maybe make all the intrinsic controls fully Unicode (UCS2) compatible? Yeah, that's a close second to 64-bit, but we've already got work-arounds for most of it.
• Fully embrace themes and DPI issues? Sure, it'd be nice, but certainly not a top priority for me.
• Get to a cross-platform environment? That's Olaf's dream, but it's totally off my radar. I'm quite happy being restricted to a Windows environment. I "get" that this may be important for others ... it's just not for me.

[dilettante]

Well I was exaggerating to paint a picture more than anything else. I just don't see 64-bit support to be the Holy Grail some seem to think it is.

To me the best way to add it isn't to play games with data types, but to just add a few types like Pointer and LongLong integers that are valid whether you target 32- or 64-bit code generation. But I haven't thought it all through because I don't feel the need for it myself.

As that blog post linked above said there just isn't that much to be gained by 64-bit user processes and quite a bit to lose.

So yeah, feel free to add the capability as long as you're making a wishlist. It just doesn't rank as a high priority for me. But if your motivation is something like "Those .Nutter bullies are making fun of my patched clothes" well to Hell with that. Man up and see that their "new clothes" leave them standing as naked as that apocryphal Emperor. Just laugh and say "short life-cycle, garbage collected, JITted, scripting language" and watch them wilt and wither in the light of day as your 20 year old programs continue running with enviable performance and responsiveness.

[dilettante]

What we need to be worried about is what comes after Windows 10.

I anticipate something on the order of an Azure Client something like ChromeOS, with only sandboxed Python and JavaScript as user programming options. Even the .Nutters should be shaking in their boots.

[DllHell]

2) it's just a marketing/perception thing. When users find out it's only available in 32-bit, they look down their nose at you for a moment. I know that last one has nothing to do with performance, but it's still a fact of life in 2019.

You can overcome this by reminding them the program is written in vb6 and watch their heads explode

[baka]

compiler is the first thing to do, this because we want back compatible.
when the compiler is done, it should replace the old one.
any project we make in VB6 should be compiled in this new compiler.
sure, we don't need p-code/native and some of the options. just a base compiler, even if not optimized. that can be done later.

i think the compiler should be both 32 and 64 bit, this to give choice.
if its much trouble to make both, i say 64 bit since we already have 32 bit.

[qvb6]

I don't see 64-Bit as "cool", but the main thing for me is extra registers, according to this Wikipedia article, it expands registers from "8 (some of which had limited or fixed functionality, e.g. for stack management) to 16 (fully general)", which would improves performance. I would say most wouldn't need the extra RAM, so it's less of an incentive.

[TTn]

I'm not sure if it was meant to be or not, but the poll should have a third option that I proposed. Simultaneous development.

I personally will limit my time on the compiler since it is not an actual deal breaker, there are plenty of other worthy things to be developed.
For those of you that want to impress others, clients, bosses, that's fine. I understand that point is valid. Although the IDE will be in the stone ages without any input, dialog, implementation, or testing.

Why are you guys so confident that the new compiler will be 100% worthy to use to build the IDE. I mean, please explain what you are thinking here. I'd rather have a final compile in VB6 first, that way we ensure parity without insidious bugs.

[axisdj]

I must be missing something, almost any project that is being considered would use an existing compiler like:
1. QT
2. free pascal compiler
3. Clang -llvm
4. embargadero c++ compiler

All these have 64 bit compiler options, It seems to me if anything is written to interpret vb6 code and convert it to be compiled by any of these 64bit would be an option.

[techgnome]

I'm not sure if it was meant to be or not, but the poll should have a third option that I proposed. Simultaneous development.

I personally will limit my time on the compiler since it is not an actual deal breaker, there are plenty of other worthy things to be developed.
For those of you that want to impress others, clients, bosses, that's fine. I understand that point is valid. Although the IDE will be in the stone ages without any input, dialog, implementation, or testing.

Why are you guys so confident that the new compiler will be 100% worthy to use to build the IDE. I mean, please explain what you are thinking here. I'd rather have a final compile in VB6 first, that way we ensure parity without insidious bugs.

The point is to expand the language and add new capabilities. That's something outside the purview of the IDE. And I never said you had to use the new compiler to build the new IDE, I simply suggested that one could. It was an option. That's usually how it goes. Write basic compiler, use it to build code to run an IDE, use that to create the next round of compiler, wash, rinse, repeat. It's an incremental process. You want 100% backward compatibly immediately... ok, that's fine... use the existing compiler, build an IDE for it, release it. But it's still not going to meet the needs of those that want VB6 to move forward. And what about licensing? There's no way around that. So a new compiler still has to be built at some point. And there's still the matter of the endless list of all the new bells and whistles that we'd all like to see added to VB which is really at the heart of all this.

At the end of the day, there's two (maybe three) driving factors behind this:
1) Seeing new features and capabilities added to VB
2) Breaking dependency from Microsoft
3) Extending the life and viability of VB as a language

If you don't expand the capabilities of the compiler, what's the point of building a new IDE for? But that's my _opinion_ doesn't make it right or wrong, it's just how I see it. I can write code in anything. But if I can't compile it, it isn't going to amount to anything. Depending on the existing VB6 compiler doesn't help either since I don't have a valid license for it. And that's my point, your IDE idea wouldn't do me any good. At least with a new compiler, I could use something like VSCode to write the code, even if it means running the compiler from the command line. Again, just my opinion, whether you agree with it or not. I'm not here to change your mind. You asked for the thinking on the compiler first thinking.

-tg

[TTn]

Tech,
Ya I get what you are saying about expanding the language, that is also what I am doing but differently. Father always taught me to use the right tool for the job, and in this case the correct tools for the job are VBA and VSTA. Not that the job can't be done with other tools. Although, VB6 was written with earlier versions, so I'm not sure I follow.

I should also point out that at some point you have to test the new compiler against the vb6 compiler, so the code already has to be dis-connectable. That is, the code can be compiled if the IDE is closed. By calling the compiler with arguments specified for the compile, in parity with VB6.exe arguments. Only then, can we test for the same results, throughout the life cycle.

I understand your license issue since you don't own a true version of VB6, so none of this applies to you at all then as a hobbyist, enthusiast developer. However, it could if a compiler can be built in the near future, at which point the IDE will already be enhanced with extra language features. Many other features can be added to the language without changing the compiler.

[techgnome]

Oh, I wholeheartedly agree that the new compiler output should be compared to the existing one. But that's something that can be done sans IDE (probably should just to eliminate it as a variable in the process). I should also clarify that development on the IDE doesn't need to wait until there's a fully fledged compiler. I just think that for an initial push, more effort should go into the compiler first, with the IDE not far behind.

-tg

[TTn]

BTW, when I say VBA, I am not talking about Office. I am talking about a host application "VB65.exe", which shares the same memory space with VBA 6.5. That equates to maximum performance, a super fast interaction directly with the language. It will be hard to match, perhaps impossible for other solutions.

[axisdj]

Something of interest regarding vb6 compilation:

https://github.com/beaverden/exploring-the-vb6-compiler

[Elroy]

... to just add a few types like Pointer and LongLong integers that are valid whether you target 32- or 64-bit code generation.

Precisely. As recently mentioned in another thread, I'd be happy with a VB6.5 that had nothing but the ability to compile 64-bit, and a new LongPtr data type. The LongPtr already exists in the VBA. It's a four-byte integer if 32-bit and an eight-byte integer if 64-bit, so it's perfect for memory pointers. All the other enhancements could come later, after this "proof-of-concept" was developed.

I'm not sure if it was meant to be or not, but the poll should have a third option that I proposed. Simultaneous development.

TTn, I don't entirely disagree, but the whole purpose is to make a point. If we have to choose, I think the opinion is fairly clear that we should develop the compiler first. Also, it prevents someone from taking something like Eclipse or NP++, giving it a make-over, and saying they've got a VB6.5 up and running. If you show us a compiler, even if we don't get to see the source code to the compiler, we know it's not smoke-and-mirrors.

I must be missing something, almost any project that is being considered would use an existing compiler...

Well, I'm not sure I can edit the poll, but ok, we could say compiler (or translator to another language so that compiler can be used).

-------------

And just to say something about "new features" ... we've got to get something up and running that'll compile our existing code, and that would be our starting place. Once we get that, then we can start talking about new features.

Personally, I think that's the mistake of several others who have actually put some time and resources into this ... trying to make sure there were new features before anything was actually up and running.

Heck, wouldn't a straight-up 32-bit, fully-VB6-compatible, open source compiler be fantastic? Pfff, you'd see MANY of us writing enhancements for it to do additional things. If we had that, we'd TRULY wind up competitive again with other languages, IMHO, in relatively short order. In fact, if we had that, I'd be shocked if someone didn't adapt it relatively quickly to other OSs.

Y'all Take Care,
Elroy

[wqweto]

... we've got to get something up and running that'll compile our existing code, and that would be our starting place. Once we get that, then we can start talking about new features.

The "compile our existing code" version will be 1.0 and this will take *years*, just check out how long it took *any* other language to reach 1.0

The starting place IMO is to have something. . . anything that looks like a compiler (upon LLVM) or translator (to C/C++)

cheers,
</wqw>

[vbrad]

Well, I'm not sure I can edit the poll, but ok, we could say compiler (or translator to another language so that compiler can be used).

This entire discussion is a bit above me but I'd have thought that this is possibly the path that gives the biggest bang for one's buck, especially if the destination is Lazarus Object Pascal.
The people in Lazarus come from Delphi, largely, which always seemed to me a community with similar expectations to classic visual basic users.
Lazarus already has an advanced open source ide and a compiler that can produce standalone executables that will run on windows, macOS and Linux.
So all the necessity to develop an ide and a compiler is bypassed and we get the benefit of tried and tested tools that are not closed source.

One of the possible problems with the alternative approaches is that there will be little to be seen for a very long time in a tangible way.
It would be a long time before anyone could write a simple project and see it work.
This would not be the case with this approach.
For example, there could be a demo vb sample project that compiles in vb6 and can after conversion be compiled in Lazarus.
From word go this project could be a working successful test, even if initially it trivially only contained a form and a button that displayed hello world when clicked.
Over time the the scope of this project could be expanded which would be great evidence of progress and which is turn might keep people interested and even attract others if it becomes well known.

As Schmidt pointed out, the work of developing a vb replacement is beyond all but a very few people around here.
I think maybe a lot more of us could contribute something to a vb to lazarus convertor. I'd be willing to pitch in, a patreon subcertainly, but I'd love to be able to do a bit of the grunt work as well.

Anyway that is how it seems to me but then there is a LOT I don't know :-(

[Elroy]

The "compile our existing code" version will be 1.0 and this will take *years*, just check out how long it took *any* other language to reach 1.0

Wqweto, I year ya. And that's why I've said elsewhere that, most likely, our best hope is to keep hoping that Microsoft will someday release VB6 into open-source.

However, on the other hand, in this specific case, we're not developing a language from scratch. We're talking about compiling a very well defined language. I'm not saying that's easy (by any stretch of the imagination), but it is easier than developing a new language from scratch.

The fractures may not be compiler vs IDE first ... however, there clearly are fractures on the best possible path forward on any of this.

If it actually worked (and worked well), I wouldn't be at all opposed to a translator.

[vbrad]

I just made a really trivial converter following on from what I wrote in my last post.
The linked gif below shows a conversion of a form only (ie not even any controls) to Lazarus and that then compiling in Lazarus.
The point is that even though it is about the simplest conversion possible it delivers something that works in Lazarus.
I don't have the skills or the time to write anything approaching a full converter but I think I could contribute something.
If a project to write a converter could be put together, I'd be willing to help.


https://imgur.com/a/wMQ81hi

[axisdj]

I just made a really trivial converter following on from what I wrote in my last post.
The linked gif below shows a conversion of a form only (ie not even any controls) to Lazarus and that then compiling in Lazarus.
The point is that even though it is about the simplest conversion possible it delivers something that works in Lazarus.
I don't have the skills or the time to write anything approaching a full converter but I think I could contribute something.
If a project to write a converter could be put together, I'd be willing to help.


https://imgur.com/a/wMQ81hi

Very Nice, thanks for that.

I am actually working in Lazarus Today. I am paying a company to convert my 100k line project to Lazarus. Once my project is done I will determine if I share the details and company name.

I actually see Lazarus as close to vb6 as possible, and I really think a converter/ or even an new IDE that can convert to lazarus code and compile would be awesome. I think its one of the fastest routes forward. the language is very close to vb6, it handles ocx stuff, and is open source, native to each OS and updated frequently.

I wonder if the same principle of vb to ast to objectPascal would work?

[vbrad]

Very Nice, thanks for that.

Thanks

I am actually working in Lazarus Today. I am paying a company to convert my 100k line project to Lazarus. Once my project is done I will determine if I share the details and company name.

That's great, I hope it works out for you, I'd imagine that it's quite an expensive business.
The figure that's stuck in my head from some time or other was $1 per line .

I actually see Lazarus as close to vb6 as possible, and I really think a converter/ or even an new IDE that can convert to lazarus code and compile would be awesome. I think its one of the fastest routes forward. the language is very close to vb6, it handles ocx stuff, and is open source, native to each OS and updated frequently.

I've never got stuck into it enough to be fully comfortable with it but it definitely feels closer to the vb ide than anything else I've looked at. Pascal is pretty OK too.

[Zvoni]

A Translator to Pascal (or any other language) is pretty much set up to fail from the get go.
Why?
1) It starts with actually simple stuff like missing properties of controls, which VB has, but Lazarus doesn't.
(e.g. The Listbox in Lazarus doesn't have a ItemData-Property)
2) Now for all intents and purposes you manage a 1:1 translation from vb6 to Pascal/Lazarus. What do you get?
Yes, you get code you can compile for all supported targets (as long as you don't use OS-specific stuff).
But is the generated code good? An algorithm/code which works as good as it can be in vb6 doesn't translate automatically to pascal-code equally good, since pascal offers way more approaches to code-solutions
(e.g. taking advantage of class-constructors/destructors in pascal, signed vs. unsigned integers)

EDIT: Why i voted for compiler first
If we're honest with ourself: Basically, an IDE boils down to be just a fancy texteditor.
I don't deny, that a really good IDE shortens developement-time by magnitudes, but the IDE itself doesn't define the language (and its features)
I still remember my first baby-steps in programming:
Open a texteditor
write code
save the file
compile it in the command-line (using all those fancy switches the IDE does for you)
run the generated executable
look for errors
Hell, does anyone remember how we debugged in those times? every third/forth codeline was a "PRINT variable" or something like that

[Elroy]

I still remember my first baby-steps in programming:
Open a texteditor
write code
save the file
compile it in the command-line (using all those fancy switches the IDE does for you)
run the generated executable
look for errors
Hell, does anyone remember how we debugged in those times? every third/forth codeline was a "PRINT variable" or something like that

I remember it QUITE well, and you outlined it quite well. I developed an application that sold world-wide in what was ultimately called PDS Basic (just before VB DOS came out). In fact, for some time, we continued to use the VB DOS compiler (but not in a way that initially took advantage of the "Visual" aspects).

Yeah, we didn't know any better, but debugging was a painful process in those days. Compile, execute, read debug printing, do code debugging, go back to compile.

Batch files for compiling were king in those days. Actually, I still use a batch file to compile my primary VB6 project, as it solves some issues introduced by compiling in the IDE.

Take Care,
Elroy

[TTn]

A Translator to Pascal (or any other language) is pretty much set up to fail from the get go.
EDIT: Why i voted for compiler first
If we're honest with ourself: Basically, an IDE boils down to be just a fancy texteditor.
I don't deny, that a really good IDE shortens developement-time by magnitudes, but the IDE itself doesn't define the language (and its features)
I still remember my first baby-steps in programming:
Open a texteditor
write code
save the file
compile it in the command-line (using all those fancy switches the IDE does for you)
run the generated executable
look for errors
Hell, does anyone remember how we debugged in those times? every third/forth codeline was a "PRINT variable" or something like that

Are there any examples of a %100 VB6 IDE clone, or clone-like application with intellisense, syntax checking, debugging etc?
Do you really think that the language and features can't be modified between what the developer types and what is compiled?

Let's not trivialize things we don't know with certainty.
A compiler may also be trivialized. But, in this case we glorify it and the achievement because it is converted from VB6.

[Zvoni]

Are there any examples of a %100 VB6 IDE clone, or clone-like application with intellisense, syntax checking, debugging etc?
Do you really think that the language and features can't be modified between what the developer types and what is compiled?

A difficult question (at least for me). But it gets back to my beginnings, when there was no intellisense, no syntax checking, no debug-symbols etc., and we still could produce working code
despite not having all those things making our life easier now. We had manuals (ON PAPER!!), we had to go through to find the titbit explaining why our code didn't work as expected

Let's not trivialize things we don't know with certainty.
A compiler may also be trivialized. But, in this case we glorify it and the achievement because it is converted from VB6.

Agreed! I'm definitely not into this stuff, so i'm the last person to ask how a compiler works etc. so i would be a fool to trivialize it.
I'm more like: "I don't have a clue how a car works internally, i just know how to use it".
That said, i still say: the compiler has to actually translate my high-level-code into machine (and executable) code, so the compiler is the actual arbiter if something CAN be translated to executable code.
In a way, i compare this discussion to a car: the compiler being the engine, the IDE being the rest (interior etc.).
An engine can run without a chassis (see test-stands), but a chassis without a working engine is pretty much useless.
So the question is: do we develop the engine ("to accept diesel, additionally to regular fuel", "to have direct access to the valves for optimizing its running"), or do we develop the rest of the car (adding fancy switches, lights, which DON'T add a single horsepower).

[TTn]

A difficult question (at least for me). But it gets back to my beginnings, when there was no intellisense, no syntax checking, no debug-symbols etc., and we still could produce working code
despite not having all those things making our life easier now. We had manuals (ON PAPER!!), we had to go through to find the titbit explaining why our code didn't work as expected


Agreed! I'm definitely not into this stuff, so i'm the last person to ask how a compiler works etc. so i would be a fool to trivialize it.
I'm more like: "I don't have a clue how a car works internally, i just know how to use it".
That said, i still say: the compiler has to actually translate my high-level-code into machine (and executable) code, so the compiler is the actual arbiter if something CAN be translated to executable code.
In a way, i compare this discussion to a car: the compiler being the engine, the IDE being the rest (interior etc.).
An engine can run without a chassis (see test-stands), but a chassis without a working engine is pretty much useless.
So the question is: do we develop the engine ("to accept diesel, additionally to regular fuel", "to have direct access to the valves for optimizing its running"), or do we develop the rest of the car (adding fancy switches, lights, which DON'T add a single horsepower).

That is fair to say. An IDE that is not 100 percent on most of the marks has already been rejected here, so we know that anything really less won't work out. It's harder than a fancy text editor, for sure.

I think the compiler takes more of a role as the wheels. We can change the tires/rims out at any time with different ones, but the car is the primary vehicle/language with rocket packs and wings. Rubber to the Road, Data to Disc. I've worked with DLL compiling and that strikes me as saving a simple file in a trickier format ...just wheels. We also don't know if these special wheels can/will be built, or used by developers considering the ANTLR/VS.NET/Nuget requirement.

Also, the additional complexity of significantly altering the compiler behavior is beyond the scope of the forum and all members here. Solve world hunger first, then we'll talk.

I am proposing that the alterations occur before the compiler. For instance when you write: If b = True AndAlso c = True AndAlso Foo= True Then. Just before the compile process these instructions can be optionally modified to execute in a faster/modern way. Now if Foo was a lengthy operation, the newer modern code will execute faster in many cases, due to "short circuiting" if any condition is false.

This behavior doesn't require the compiler to be any different. Obviously, I am using the vb.net form, which at compile time translates to If b = True Then, nested below that, If c= True Then. The OrElse keyword is a little bit different but it also short circuits if any condition is true. The behavior is significant and flexible enough that we can't trivialize these as mere optimizations either, or simple build events etc. These are language enhancements that VB.NET received and VB6 did not, and they aren't just NET hype.

The IDE is the language operator, and the feature set and enhancements are in the IDE, with the instructions of what is to be compiled controlled by this custom IDE.

[Zvoni]

TTN, ahh, ok.
I get what you're alluding to with the IDE.
You mean to say, that a "new" IDE can/could preprocess our new/modern code/"new" features in a way, that the "old" compiler still could understand (your example with short-circuiting If-Then-Else is one of those shining examples).

I agree to a degree.
What you're describing are not actually "new" features, but existing ones just with different clothes on.
To stay in your If-Then-Else-Example: short-circuiting an If-Then-Else was always there, exactly in the way you described (which i still do until this day. Never was a friend of those horrid And/Or/Not-constructs).
it just looked different to what other languages offer. But that's just my personal opinion.

What i was talking about are real "failures" of the compiler:
signed/unsigned integers (I'd really be interested, if there is a way to teach our current compiler to accept unsigned integers).
writing own operators
Class-Constructors/destructors (i don't count the Class-Initialize-Event as a constructor)

*sigh* i really don't know if i should mention pointers here, since one of the "charming" properties of classic VB was, that it was hiding all the gory details behind the scenes (memory-allocation, garbage-collecting etc.), but i think it should be the programmers decision to use them or not.
and don't get me started on the age-old struggle with cdecl vs. stdcall API, and the hoops you have to jump through to make them work.
and i'm pretty sure, that i have left out a mountain of other topics where our compiler comes up short and wanting.

Yes, i agree to 100% that a "new" compiler is a tall order for the members of this forum, and i agree with Olaf (and others), that there are maybe max. 3 or 4 people here who might have the knowledge and the skill (please note: I'm not saying anything, if they have the time! And i'm definitely not saying anything for or against knowledge/skills of anyone here, me included!).

In a way, i have to agree with the statement, that as long MS doesn't open source the VB6-IDE and compiler we're going to be stuck with it, with no VB7 in sight.

[TTn]

TTN, ahh, ok.
In a way, i have to agree with the statement, that as long MS doesn't open source the VB6-IDE and compiler we're going to be stuck with it, with no VB6.5/VB7 in sight.

If you guys don't mind, please stop using VB6.5 to represent the name of an imaginary IDE, since my project is in fact the true VB6.5 IDE from Microsoft, heavily modified to be integrated with VB6's intrinsic functions. In other words, that name is already taken. Some people casually reading these posts may assume that my project is in an imaginary realm, which it isn't. I just don't want to detract from the real progress on the subject, versus speculation.

It would be nice for MS to open source the compiler, since the IDE SDK was already licensed, exactly for this purpose. A petition to open source the compiler now would be awesome!

[wqweto]

@TTn: How can your VB6.5 project be downloaded/tested? Is VBA SDK 6.5 freely available?

I downloaded VB65190623.zip but the single .exe is closing immediately here (probably missing dependencies).

cheers,
</wqw>

[TTn]

@TTn: How can your VB6.5 project be downloaded/tested? Is VBA SDK 6.5 freely available?

I downloaded VB65190623.zip but the single .exe is closing immediately here (probably missing dependencies).

cheers,
</wqw>

On the website vb6x.org, at the bottom there is a link to: VB65 IDE (open source - requiring installation of SDK and VB6 - The host must be "Run As Administrator" in restricted paths)
You need the SDK installed(found just above that link is the iso or zip), and VB6 of course. The VBA SDK is also on our Github spot, if you prefer that

The current version 6/23/19 on the web site has a bug if you add a standard module without a sub main.
The error is fixed in the source code now, it was due to a recent update where I added code to check for Sub Main's and a missing startup form.
That error was actually because VB did (would) not initialize the return value of the class I wrote, when there is no sub main. The solution was to return Nothing instead, and handle that from outside the scope to avoid the quirk all together.
This version should be relatively solid, please play with the code formatting options and look for code that does not collapse/expand (code folding), or has errors during collapse/expand.

BTW, ComCtlsDemo 1.5 and 1.6 do work inside this IDE. However, If you add many of these custom controls, you may run into weird sporadic errors probably due to memory errors. Subsequently, you can't add controls without restarting the IDE, otherwise you get a generic error: Can't create ActiveX... The problem is that you lose work, so at this point we will have to figure out what is wrong with the controls in relation to running in this context. See the image on my web page of VBCCR15, with separate controls selectable for each.

[wqweto]

Took me some time to figure out the link was to Visual Basic for Applications SDK.zip *opened* for browsing in the fancy dropbox UI and that still there is [Download] button with "Direct download" link in the upper right corner of the page. Kind of like on the 4-th floor but w/ the staircase missing, no electricity and an escaped tiger in the same building. . . :-))

cheers,
</wqw>

[camomille]

@TTn

Hello,

I installed your latest version Visual Basic 6.5 IDE (Latest version updates 6/23/19) and I started to successfully test the * .vbp files runs correctly, you said "The number of undos can be increased", but I have not found how, can you tell me the procedure.
thank you for your work

Alain

[qvb6]

There is no need to add AndAlso/OrElse to support short-circuiting if we do it the Pascal way. In Pascal, if the two operands are of type Boolean, then a logical operation is done with short-circuiting, but if both operands are numbers, then a bitwise operation is done instead. So there is no need for extra keywords. So for example:

Result = Bool1 And Bool2        ' <--- Logical with short-circuiting
Result = Number1 And Number2    ' <--- Bitwise, because both are numbers
Result = Number1 And Bool2      ' <--- Type mismatch, or default to Bitwise
Result = Bool1 And Number2      ' <--- Type mismatch, or default to Bitwise
Result = Not Bool1              ' <--- Logical Not
Result = Not Number1            ' <--- Bitwise Not

If I have numbers and I want logical operation, I could use "<> 0" to turn it into Boolean expression, so for example:

Result = Bool1 And Number2 <> 0

Also, I am not sure, but in Pascal, one could change this behavior by using #pragma(Similar to Option Statement in VB6). We could add "Option ShortCircuit On" to turn on this feature.

[Shaggy Hiker]

That's pretty much how .NET does it, except that AndAlso and OrElse are there because you almost always want to short circuit, but not ALWAYS, so And and Or are still there for Boolean expressions when you need to evaluate all pieces. I believe that there is always a different way to write code such that you never HAVE to evaluate all pieces, so you should be able to get away with avoiding the AndAlso and OrElse operators, as long as people know that they will either always get short circuiting, or never get short circuiting. I assume that the pragma you mention would choose between those two, and that mixing the two in code isn't allowed (unless you can turn on and off the pragma).

[yereverluvinuncleber]

When I go into my garage, or my art studio, or wherever I go it is all about the tools I use to express myself. How the tools handle, their familiarity to my hand, how I wield them, how they respond to my touch, where they are place in my various toolboxes. That is the human interface to the toolset. That in language development terms is the GUI, the IDE.

How the tool does the job is up to the tool, how I wield the tool is down to me and the interface the tool provides. Therefore, for me the interface between the tool and the user is the most important element. The VB6 IDE is essential to get 'just right' to make people productive and to get them going.

I understand that for the sake of efficiency and logic that having a compiler that can self-host itself and then be used to build the IDE makes good sense and would be the best way to go but it has also been that way for a long time now but we have very little to show the world that might impress them or be used in anger.

There are other ways... Make steps toward an IDE using existing technologies that allow the dev to get the job done in more realistic timeframes. It proves the point, it makes a clear statement to the world of our intentions, it gets people on board. It shows VB6 development is actually still a sensible thing to be doing.

32/64bit? I don't really care that much but I know it will be important for the future for some. The kudos too?

If I can write in VB6 in something 85% akin to the VB6 IDE and it comes out as a Win binary that can do all the API stuff that VB6 does - and most importantly has the potential to grow and improve - and be supportable then I'd be happy to use it. I'd probably still use the VB6 IDE simultaneously until the new version began to have functionality that made migrating to the new impossible to avoid. Be aware that I still use Photoshop CS ver 8. as it is what I know and is quick and amazing, so it would need to have some significant improvements before this old bu@@er would use it (installs on Win10 easily &c &c - see my wish list).

However, I wouldn't use it at all if the interface failed to be there beneath my fingers in all its facets exactly as the VB6 IDE does. The new IDE needs to actually 'be' VB6 before I would use it.

The compiler - well that is 'under the bonnet' or 'beneath the hood' as those from the US say. The users, do they give a monkey's cuss as to how it is achieved as long as it is achieved?

A self-hosting compiler and an IDE written in VB6 seem a bit of dream given how this able crowd hasn't got its act together as a team despite all the brains and the knowledge that it has at its disposal. Sorry if that latter sounds cruel but it appears the truth from my limited view point.

[yereverluvinuncleber]

I remember it QUITE well...Yeah, we didn't know any better, but debugging was a painful process in those days. Compile, execute, read debug printing, do code debugging, go back to compile.

When programming my desktop widgets I still use that method. I have the advantage of using Photoshop as the forms designer, a script that converts from a PSD to an XML that the widget engine uses - and a reasonable debugger that is used at runtime and an advanced programmer's text editor. You can create something akin to an IDE giving a lot of the functionality it provides but the integration bit that an IDE does, is sorely lacking.