classic vb was ugh. what a terrible, terrible language, development environment, framework, everything. its only good part was that it was so simple compared to Visual C++. there was no compiler, linker, resource editor, debugger etc. the ide did everything. code was reformatted automatically to a hardcoded style. what a harmful environment for learning, jesus, it literally prepared you for nothing but more visual basic, forever. based on ole but didn't support all of ole: some parts couldn't be used (non-stdcall methods and functions for example), other parts could be used but not implemented in visual basic (methods named like reserved words could be called, but not implemented. jesus christ... among others, this forbade you from implementing the entire IEnum family of interfaces, meaning you couldn't create proper, first class collections in visual basic), others worked like shit. error messages contained the line number of the source file... if you explicitly added line numbers at the beginning of the line, like in ms basic 1.0. you could only link c/c++ code dynamically but you couldn't use import libraries, you had to manually write import statements. except import statements were slow and late bound, to get real dynamic linking you had to use type libraries, which unbeknownst to many could also act like import libraries, defining free functions in addition to coclasses and interfaces. this was, of course, completely undocumented

visual basic was yak shaving, the programming language. you literally spent most of your time working around bizarre limitations of the language. say maybe you want to create a file with a unicode name? no problem right, visual basic strings are OLE BSTRs, natively unicode, just pass it to CreateFileW. except! if the filename argument is declared as LPCWSTR (internally, an alias to the same identical type as BSTR, i.e. a pointer to a wchar_t. they aren't the same exact type, but close enough), idiot pissclown visual basic will first convert the string to the current charset, lossily, and then convert it back to unicode and pass it to the function. you had to declare the string arguments as long, and instead of the string, pass the return value of StrPtr on the string (StrPtr being an undocumented visual basic function that returned the address of the first character of a string as an integer). jesus christ. you couldn't allocate dynamic memory! want to call a win32 function that fills a buffer with a string? use function Space to create a string of space characters of the desired size, pass it as the buffer. thank GOD kernel32 exported, entirely by accident (the accident being the need to share the same exception handling binary code between windows, windows nt user mode and windows nt kernel mode) vb-friendly equivalents of memset and memcpy, which were total godsends

how could it suck so hard? how could microsoft release such an obviously half baked product? well, the idea was that you wouldn't write your entire application in vb. rather, you'd write the business logic in visual c++, expose it as activex objects which internet explorer could load and feed with untrusted data from the internet, and then write the ui in visual basic. but visual basic programmers rarely did that, and expected to write everything in vb (not unreasonable), and kept slamming into wall after wall. microsoft mvp bruce mckinney wrote a book on standard programming concepts, except visual basic. the book was titled "hardcore visual basic" because getting vb to act like a big boy programming language was so goddamn hard

provided you survived the vb gauntlet and wrote a working, usable program, you didn't even get a proper installer. vb programs couldn't run on their own, they required a runtime library to be installed first (no static linking!), plus all the activex controls they used (the only kind of component supported by vb), so an installer was a must. at the time, visual studio came with a license for the basic edition of installshield. visual basic, on the other hand, came with a shitty, cheap-looking installer that wasn't even customizable. like a final spit in the face of the hobbyist

delphi was so much better it was ridiculous. it could do everything vb did, and much much more. static linking was not only possible but encouraged, so you could freely use dozens of free components, that often came with sources, and didn't even need to be installed, and couldn't be downgraded by shitty installers, or loaded by malicious web pages without your knowledge. the vcl framework was the best way to develop native win32 applications, save for a couple bizarre choices - like, you could tell that an application was written in vcl by the fact that, no matter how many windows you opened, the application only appeared once in the taskbar, with a button that didn't match any of the windows. it was because vcl created a hidden "master window" for the application, and all other windows were created as children of this master window. a bit like how window management works on the mac, but on windows it was super annoying and there was no way to opt out. also delphi like c++builder used the borland proprietary omf format for static libraries, instead of standard format coff, meaning they couldn't interoperate with visual c++ in any way, even getting the two environments to agree on dll import libraries was a little miracle that rarely happened

#justearly2000sprogrammerthings