VB6 not dead

[Mike Lobanovsky]

I used to have a few VMware v8 VMs under my XP when MS dropped XP support a few years ago. I migrated them to Win 7 on another PC and uninstalled the older VMware. But it often happens that deinstallation isn't as clean as it's supposed to be. So, one of VMware's numerous DLLs remained dormant in my \system32 subfolder where I didn't have a chance to spot it for the life of me among a thousand other DLLs that had piled up there since my most recent clean XP install circa 2005. I noticed that my XP started to take unusually long to boot. And Event Viewer helped me to spot and mark for deletion-on-reboot the offending DLL that was simply trying to pull in over and over again the entire VMware v8 installation from the server that wasn't offering it for download any longer because VMware had proceeded to v10 in the meantime!

The directory you mentioned might well have been not the true cause of conflict in your particular case. But analyzing the logs usually helps to find out exactly what might be happening; you just need to know where to look for them, and Event Viewer is the correct place for this under MS Windows. Probably your VS 2008 installer now rolled a couple of newer files on top of those that are used by both IDEs and that might've been incidentally overwritten with older versions by the VB6 (re)installation, and now the entire conglomeration can coexist peacefully again. MS servers usually take time to connect to and that's what might have been causing the delay in launching your VB6 IDE.

[Mike Lobanovsky]

That may be true for virgin VB6 but with the use of the VBCCR13.OCX replacement for the Thunder classed controls, I don't think that is still a limitation.

That's really not a limitation but just additional PITA. Either way, I think it's not really Thunder controls that you should be after but rather the IUP controls to make SB GUI friendly in both Windows and Linux. Leave the Thunder controls alone to be handled in their native VB6 IDE environment; there's no place better for them than that. Get your own IUP forms editor up and running instead. VB6 and VBCCR13.OCX will be just a welcome Windows-only bonus.

[John]

You're right and I need to stop getting side tracked with the lure of using VB6 as a OCX forms control with a COM/OLE SB connection. Dave already has something worth building on and I'm pondering if I should just live with the IUP dialog editor and property sheet or wrap it with VB6?

[John]

I decided to do a rebuild of the Script BASIC COM extension module and was surprised how it went from zero warnings to 334. 

After adding _CRT_SECURE_NO_WARNINGS to the C++ preprocessor definitions,  I'm down to 137 warnings. 

[Mike Lobanovsky]

I decided to do a rebuild of the Script BASIC COM extension module and was surprised how it went from zero warnings to 334.

My condolences. You will have to revise your project/solution settings after your recent re-installation of VS 2008 components that evidently took place while you were out for your cup of coffee.

... I should just live with the IUP dialog editor and property sheet ...

John, that's in fact a serious strategic question. That's what I'm pondering over too in relation to the projected FBSL (?) v4.

Firstly, an attractive BASIC must use the GUI elements native to the OS it is run-/-ning/-nable on. Look at VB6: its Thunder controls are 95% native in their underlying implementation yet they look completely alien under modern Windows unless we take emergency measures in the form of extra side-by-side manifests or embed them in VB6 executables directly using 3rd party tools or VB6 environmental hacks.

Secondly, IUP, and wxWidgets, and Qt, and almost everything else of similar kind seems to be too huge to be bundled with a medium sized BASIC on anything but Linux where they belong and where their components are in fact standard system equipment. A 260KB-large all-in-one FBSL binary simply CAN'T allow itself to be bundled with 5MB of GUI framework DLL hell that's going to falter every now and then where the native Common Controls sell for nothing and are rock solid. Nor can you efficiently isolate only what you need from these frameworks because their devs are steadily sailing away from simple widgets to a common easier-to-maintain core and peripheral control-specific wrappers good for nothing without the huge core they have to pull in. (and the situation only gets worse with every passing day while we're still unsure even where to begin)

Thirdly, these frameworks' interfaces are far too atomic to fit in the BASIC paradigm. Look at what IUP offers to interface your apps with! OMFG!!! You need perhaps two dozen distinct function calls and a verbal markup script into the bargain (!) just to get a simple button up and running in your app's GUI window! It is in a bad need of much, much simpler higher level wrappers and a compos visual designer with direct code generation to become minimally practical for everyday use. There is absolutely no reason for a C or BASIC programmer to have to code extra XML/HTML/Python/younameit stuff to spawn a hello world popup on the user screen!

I'm very grateful to AIR for pointing me to that LIBGUI stuff. It seems to be just about right in its ripeness to start falling into the same trap of "universality" as all its predecessors, but yet recoverable to its distinct constituent components that are the only meaningful and usable parts of any project in this area of program development.

[Mike Lobanovsky]

Try to add _CRT_NONSTDC_NO_WARNINGS to suppress POSIX warnings as well. I think Dave was rather using a make/bat file to compile the sources if these macros aren't defined in the solution/project file settings he supplied you with.

Or he was still using VC6 to compile them, as I suggested you should do too...

[John]

At this point they are warnings and giving me a ToDo list when I have time. If this was more than an IDE/Debugger, I might be more concerned. My gcc builds were void of warnings so on to better things.

Dave built the COM ext. module with VS2008. He even did a video of how to set it up for the project. My guess is Dave didn't feel the warnings were concerning in the development phase and I didn't discover them until the rebuild.

[Mike Lobanovsky]

Given what you say, I'm 100% sure he was simply ignoring them. Judging by your log file and his C vocabulary, it is obvious he meant the sources to be linked against msvcrt.dll rather than the VC9 extra distributables.

[John]

I think a bit of history would clear things up how things evolved.

Peter created the dbg.so debugger with the the main goal of showing how C preprocessors are used with Script BASIC. This was a Windows console mode preprocessor that used Windows console mode specific API calls. Before Peter moved on, he gave me the 2.1 beta release to setup an open source effort with. He wrote a GUI remote version of the debugger called sdbg.exe. It was buggy and I converted to a console remote debugger.  (dbgcon) When Dave came along he built on Peter's effort but used VB6 and eliminated the socket interface for something more direct.

[Mike Lobanovsky]

Thanks for the clarification, John.

Whoever was the author of the C code you're immediately compiling was using a classic C language runtime library's vocabulary to formulate this code, and the offending function names you're seeing in your logs have no particular console or GUI flavor.

Since probably 90% of all Windows executables have been and still are compiled using MS VC compilers, msvcrt.dll (it dates back to VC6 times) has become a de-facto standard for Windows apps that have no use for more modern MS VC bells and whistles and anti-buffer-overflow solutions and redistributables that MS is coming up with in every annual edition of yet newer Visual Studios. Naturally these newer IDEs aren't very happy with this, and you won't see an explicit prebuilt option in them to allow for linking to the "deprecated" DLL. Hence my original advice to use VC6 and its IDE to avoid likely "false alarms". Another known hack would be to use a VC6-only installation without its IDE but instead to point your VS2005/2008 project compiler, include, and library paths to those of VC6 rather than VC8 or 9.

But probably I'm meddling too much in what isn't supposed to be my concern. I apologize if that is really the case. You know you are always free to trim my input to reasonable bounds if need be.

[John]

But probably I'm meddling too much in what isn't supposed to be my concern. I apologize if that is really the case. You know you are always free to trim my input to reasonable bounds if need be.

This is an open topic about VB6 and its continued viable use. I just happen to be using Dave's stuff as a working example and the problems I've run into.

Keep in mind that most of SB VB6 IDE/Debugger is standard scriba and dbg preprocessor code that VC2008 is complaining about. We can't blame Dave for that.

[John]

I ran across this VB6 based form designer that looks promising.

Let me know if you think this would be a good place to start.

The one thing that I'm going to have a hard time giving up is the real time editing of a running form.  Maybe with a bit of help from VB, I can make the IUP dialog layout editor look a little better.

[Mike Lobanovsky]

John, you already have 4+MB of dependencies in your VBCCR13.OCX. You're gonna have another five in your IUP framework. Why would you be willing to pull in yet another megabyte of DD-specific ActiveX'es and core C dependencies? Let alone COM that's strictly Windows-specific? There won't be any cross-platform code compatibility between Lin and Win SB this way.

OTOH BMFD/FMFD are tiny and self sufficient, and their code generators may easily be re-oriented from Common Controls to IUP or another GUI framework of your choice. There are a zillion eye candies written in VB6 but you won't be able to use them anywhere outside Windows COM, or even look through them all in your lifetime.

Just saying.

[John]

Good points and made me realize how easy it is to get fat. For this round of the Windows 32 bit release I'm going to stick with what Dave gave us and the IUP dialog editor/designer. I think the end goal should be a cross platform IDE/Debugger written in C BASIC/IUP.

There are a zillion eye candies written in VB6 but you won't be able to use them anywhere outside Windows COM, or even look through them all in your lifetime.

It's just nice to know that VB6 isn't dead for the everyday tasks and games we all loved doing in the past until Microsoft abandoned us for .NET.

Unfortunately not enough people realise that VB stands for Very Best. 

[Mike Lobanovsky]

Unfortunately not enough people realise that VB stands for Very Best. 

Absolutely!