Main » Programming » Resurrecting Visual Basic 3 shareware in VB6 » New reply
    Alert
    You are about to bump an old thread. This is usually a very bad idea. Please think about what you are about to do before you press the Post button.
    New reply
    Post help

    Presentation

    [b]…[/b] — bold type
    [i]…[/i] — italic
    [u]…[/u] — underlined
    [s]…[/s] — strikethrough
    [code]…[/code] — code block
    [spoiler]…[/spoiler] — spoiler block
    [spoiler=…]…[/spoiler]
    [source]…[/source] — colorcoded block, assuming C#
    [source=…]…[/source] — colorcoded block, specific language[which?]
    [abbr=…]…[/abbr] — abbreviation
    [color=…]…[/color] — set text color
    [jest]…[/jest] — you're kidding
    [sarcasm]…[/sarcasm] — you're not kidding

    Links

    [img]http://…[/img] — insert image
    [url]http://…[/url]
    [url=http://…]…[/url]
    >>… — link to post by ID
    [user=##] — link to user's profile by ID

    Quotations

    [quote]…[/quote] — untitled quote
    [quote=…]…[/quote] — "Posted by …"
    [quote="…" id="…"]…[/quote] — ""Post by …" with link by post ID

    Embeds

    [youtube]…[/youtube] — video ID only please
    Thread review
    tomman Speaking about Road Trip: the game turned out to be quite fun, but the AI/RNG is just horrible, plus the game is a pile of bugs:

    - If you need a specific Solution Card to counter a specific Hazard Card, chances are you're going to draw pretty much every Solution Card in the deck except for the one that you need, while your opponent gets all copies of the card that it's useless to him. This quickly leads to nasty no-win situations because there is no balancing whatsoever, basically killing the "skill" aspect of the game.

    - When you win, sometimes no matter how many times you dismiss the game summary dialog, it comes back as soon as you hover your pointer over the game field or menu bars. This seems to be due to a timer going amok.

    - You're supposed to get a 14-day trial, but it seems that all you get is a ONE-DAY TRIAL due to the very botched way of the game to parse dates: their "software protection" method stores on its fake DLL the installation date as the day of year, which is calculated by extracting the day and month of the current date, which is done using Val(Mid$(Date, n, 2)), where n=1 for the current month and n=3 for the current day of month. If you already spotted why this is BLATANTLY BROKEN, chances are you don't live in good ol' US of A because if this dev ever read the VB docs he should have known that the string representation of a date this way is locale-dependant! (The correct way to do it is to use Format$ with a custom date format, Day/Month built-in functions, or even better: DatePart which already gives you the day of year, although that one required shipping an extra DLL back then because that for whatever reason, MS considered DatePart to be a "financial function", which depended on MSAFINX.DLL)

    - Their "software protetction" routines also store some other unknown stuff on said fake DLL, even on the registered version (according to leftover code on the shareware executable - the methods were exactly the same except for the botched trial expiration part)

    The history of this game ends sometime after 1997, when an update was released (this time the dev had updated to VB4, but the app was still 16-bit, and aside extending the trial period to 30 days and replacing the custom ROADTRIP.VBX with VBIO.VBX and COMDLG16.OCX, the bugfixes -if any- are unknown), promised Internet play for future versions, and promptly vanished from the Internet before crossing the bridge to the new millennium. A pity, as I genuinely see some potential on this card game...

    UPDATE: Road Trip is a computer implementation of the French cardgame Mille Bornes ("thousand milestones"), which is played with actual cards. Nice~
    tomman Let's check another collection of old forgotten shareware on CD, this time I borrowed some bits from Walnut Creek's Giga Games series (discs 3 and 5).

    Their info files are a mess, and they don't even tell you most of the times if your game needs extra libraries, like the VB ones, so this time I only managed to checkout a few samples:

    - BJ_POK33.ZIP: More Ultisoft shareware, but this time it is NOT another reskinned slot machine simulator! QCARD.DLL consumer and has SSFrames, but otherwise it doesn't share the same sins as their video slot games (string font sizes, mainly), so pretty much a straightforward port. All these Ultisoft games feature a catalog of their complete shareware lineup, which upsets VB6 because it features >1024-character lines, which causes the IDE to refuse saving anything at all until you break up those lines. No, nobody (be it sane or clinically insane) does one-liner complex functions in VB - these guys instead fitted all their catalog descriptions in code which led to the ridiculously long lines. Unlike most Ultisoft products, their shareware card games shipped separate executables built from different codebases for shareware and registered products, so there is nothing to unlock here - the nagscreens are here to stay, including the catalog dialog that was now promoted to an actual nagscreen too!

    - HS32.ZIP: MOAR Ultisoft gambling simulators - this one is particularly lame (but so are actual horse races to me). Once again, nothing noteworthy to write about, except for the fact that this continues the Ultisoft tradition of hardcoded regkeys. NEXT!

    - LASBLO20.ZIP: Oh joy, a rare VB4/16-bit sample! I thought nobody bothered with that release (either stick to VB3 until it was practical to do, or jump ship to Win95 and the promised 32-bit land ASAP). Unfortunately this means I can't do anything at all since there is no VB4 decompiler :/

    - MIMA250.ZIP: Some shitty Missile Command clone from Canada made in VB2 (DoDi may bitch with some non-errors, but the decompiled code is useable). You fight straight lines ICBMs with useless missiles. DoDi kinda lost its mind when dealing with those raster opcodes (looks like the dev declared all common opcodes, but only used SRCAND and SRCINVERT, but DoDi came up with invalid values and byteswapped values on comments, including a freakishy long one), but I guess I got those right at the end? This game uses the MCI control for playing MIDIs via MCI commands, yet it resorts to sndPlaySound for playing WAVs!? Madness. Lots of dead code, and a single global boolean variable controls what target is built (shareware vs. registered), but the name/serial validation routines are missing (if they ever existed, but then there is no code to load name/serial from an INI file).

    - RDTPV10S.ZIP: Someone that liked card games and auto racing decided to find out what happened when you combined both, and this is the result, a somewhat entertaining piece of shareware. This one was fun - two custom VBXs with no 32-bit replacements:
    * WAVE1.VBX (actual name: WAVE.VBX from Mabry Software): For those devs that were too lazy to wrap sndPlaySound and/or found the MCI control overkill. I didn't even bothered with this one - moving this to sndPlaySound(SND_ASYNC | SND_NODEFAULT) only took me like 3 minutes for the 18 WAV files this game uses.
    * ROADTRIP.VBX: This one is a really custom control (not just a generic 3rd-party control made by someone else), coded specificaly for this game - it's a glorified imagelist, except that it ships with hardcoded images ("resources") of the custom card deck designed for this game. Naturally this means that this VBX is useless outside this game, and therefore there is no point looking for a 32-bit OCX, as this game never got a 32-bit release despite being released in May '96. The replacement involved carving the VBX for the card deck images (which were good ol' .BMP files, complete with headers instead of just raw bitmaps) and MS Common Controls ImageList, which with minimal code changes served the exact same purpose.
    So basically I ended trading away two unknown VBXs with a single API call and a standard MS OCX. I could have put all the card images on a single bitmap, letting me to use PicClip, or even do away with external dependencies and just BitBlt some cards but the key here is to be lazy :P Shareware source base, the highscores dialog is there (complete with its backing code!) but the actual menu item event handler just serves a "Please Register" messagebox. Now let me talking about their "shareware protection" bits: this game enforces a 14-day trial, and once it expires you're locked out. For this, the game creates a fake DLL (mci00826.dll) on C:\WINDOWS\SYSTEM\, a hardcoded path, which is bound to fail on those rare Windows installs back when MS allowed you to setup Windows on whatever directory you wanted. Oh, and that's a no-fly zone on anything past XP, or NT without admin privileges. This game also does something incredibly lame: it checks its 18 WAV files on boot to ensure their file sizes are consistent against an internal table, and bails out if you have changed even one of the files... yet there is no error handler on that proceudre, so the program will crash instead at the first missing file. I guess that too served their purposes as well.

    - SOL3.ZIP: Packed installer EXE, so I'm leaving this for later as I'm lazy to fire up the VM and install.

    - USC22.ZIP: Yet another Ultisoft shareware card game, and as you've expected, this is the crippled shareware binary. There are previews of the games only available on the registered version, but no actual code to drive those, so there is nothing to unlock here :/ QCARD.DLL consumer, and it uses almost every API function, even some of the "undocumented" ones!
    tomman TIL there is no working decompiler for VB4: DoDi's VB4 solution is a disassembler - he never managed to complete a working decompiler. He did started work on a VB5 disassembler but that effort too led to nothing. His VB decompiler pages were deleted around mid-1999, and he switched to Pascal crosscompilers shortly after that, putting an end over his VB decompiler saga.

    With some effort you can find the original VBOPT4.EXE release for version 4.11 (there is a later 4.12 which was eventually released by scene groups, but that one is now lost forever?) and its VB6 "rebuild" by the same guy that decompiled and rebuilt the original VB3 decompilers. But don't get fooled - this is not a proper decompiler by any stretch of the meaning: it CAN output some code, but nothing else! It only works with really simple executables (the only one I've got working with was the Setup executable from the VB4 Setup Toolkit, and even then it generated unusable code), it can't save, and it crashes a lot.

    Here is a quick list of what tools are available out there for decompiling all known Visual Basic versions:

    - VB1/DOS: Nothing :/
    - VB1/Win: Nothing :/
    - VB2: DoDi
    - VB3: DoDi
    - VB4/Win16: Nothing :/ (DoDi's may recover forms and some code snippets, but that's all)
    - VB4/Win32: Nothing :/ (ditto; also Semi VB Decompiler claims it may recover forms for 32-bit VB4)
    - VB5: VB Decompiler, VBReFormer, Semi VB Decompiler. VB5 introduced the native compiler that really complicates decompiling efforts. No decompiler claims 100% compatibility, but VB Decompiler boasts it can recover the most code when matched against the competition. VBReFormer does not support p-code executables. These two have crippled lite/free (read: useless) versions, but their Pro products aren't insanely priced if you really want to get serious. The "semi" on Semi VB Decompiler is there for a reason: it can barely recover any code, if at all! But on the flip side, there is a Github repo with sourcecode (!!!). YMMV.
    - VB6: Same options as VB5.
    - VB .NOT: Many. Native compiler is gone for good. Unlike p-code, MSIL/CIL is documented and decompilers are abundant, both free and commercial.

    Realistically speaking, if you lost your Classic VB sources, your options are not good. Very old VB1 code is unrecoverable, for VB4 you only get a sneak peek, for VB5/6 you're expected to spend some cash just to get forms and half of your code if you're lucky and planets align, and for VB2/3 you've got the greatest chances to recover code you can recompile into a working executable (or even port it to Win32!), but it's not a straightforward procedure by any means, yet it's fully doable if you're willing to endure some pain. And dealing with obsolete ActiveX junk.

    Those New Coke VB.NOT folks got it easy: anyone can steal their sourcecodes for free! No registration, no SMS, FREEEE!. Sure, there are ways to protect your code, but (outside of people selling 3rd-party controls and libs) who bothers?
    Kawaoneechan If anyone could go eat a bowl of fuck it was those companies, then.
    tomman Let's get this PCKENO/BACCARAT combo done, after much intense preliminary work:

    As I've said, this couple shareware Lose Your Money Simulators™ are from the same author and use the same bunch of VBXs, some of them being terrible in the way:

    - Crescent (Sax) QuickPak (CSGROUP.VBX / QPRO200.DLL): You have to crack the installer (it's a 4-byte patch) in order to bypass the $800 BS fee for lameloid controls that haven't been updated since 2003 or so. This is a mixed bag - of all the original QuickPak controls, CSGroupBox (aka sivbGB) was the only one that didn't made it for the promised ActiveX land, so a direct upgrade is not possible. But what the hell is a CSGroupBox? Nothing but yet another fancy Frame container! You can actually make a pretty convincing replacement with our good old friend, Sheridan's SSPanel From Hell:

    Separated at birth? You decide! The makeshift version is pretty much pixel-perfect, at least on VB3. You still have to spend quite some time moving, cutting and pasting controls around with VB3's barebones form editor (of which VB6 builds on it, adding next to no improvements - you can't still drag to select multiple child controls inside a container control!). This is the most labor-intensive part of the port, since it's very easy to screw up the original layouts if you aren't careful.

    The other part of the equation is QPRO200.DLL (its 32-bit counterpart is QPRO32.DLL), which is a "bonus" utility library that ships with QuickPak, featuring all classes of useful functions. Some of them are very broken (WinDir doesn't bother cleaning up the return string so Win32 consumers will break, so you should be properly using GetWindowsDirectory anyway), some of them silly (Encrypt2, seriously?!), and some of them redundant when used with newer VB versions.

    - FXTools (FX***210.VBX): Ugh. Did shareware developers paid $400 for this bunch of horseshit back in 1995 when the 32-bit version was new!? I have no qualms over the original 16-bit VBXs, but their 32-bit counterparts are so fucking broken I can just imagine that Pegasus tried to bury the product as fast as they could, if only to prevent lawsuits. They eat CPU time for no reason, fail to render properly (FXShape), don't let some other specific widgets to be placed/rendered over them (like standard Labels), and are completely unusable on design time! This hurts PCKENO badly, as this app uses FXShapes to draw the keno balls at the game table form top. Don't ever try animating ANYTHING AT ALL, or you will deadlock your UI thread, BADLY.

    - MediaKnife (MKTLS16.VBX): Another terribad 32-bit port of a $400 "multimedia/FX" set of controls - these games use it only for playing WAVs (because sndPlaySound was too easy/hardcore for this specific author I guess?) that aren't even shipped with the shareware versions! MediaKnife installer is also broken due to its use of GetDiskFreeSpace API that returns incorrect values for partitions larger than 2GiB (Microsoft was discouraging developers to move to GetDiskFreeSpaceEx since before Win95 went RTM, but not many Win32 compilers could deal with 64-bit integers back then... even on VB6 you have to resort to a dirty hack!), so it may not even let you install the product on some setups out there depending on how the result overflows (it didn't let me on my 15GiB XP partition on my ol' HP laptop, yet it succeeded on my nearly-empty 40GB test VM). The installer was made with PC-Install, another defunct program from yet another long-defunct software shop, but thankfully the fix is a single instruction (2-byte) patch to override the GetDiskFreeSpace check.

    After littering my registry with more ActiveX junk, spending a couple days with those CSGroupBox replacements (not difficult, just boring as hell), and upgrading API calls, I was done. I don't understand those Vegas card games, and Keno sucks, but whatever :P

    Registration notes: This executable uses license files (.LIC), 3840-byte binary blobs that are structured in 96 0x40-byte string records. Each record is encrypted using QuickPak's Encrypt2 lameass XOR-based crypto (seriously: they even say on the documentation that you should not rely on it for anything serious) using one of two keys:
    - "gouofawildcatsgobeatasuyoustudmuffinsyou" for even records
    - "eatabowloffuckyouslutmonsteryoufagfucker" (no kidding!) for odd records
    The odd records are ignored - all relevant license fields are stored on the even ones, twice. If any record pair mismatches, the license is rejected and program assumes it's in trial mode (to reset your trial, delete any WIN31EX_.Z@? file on your Windowas directory
    This also implies that all you need to unlock the full version is a 3840-byte blob full of zeroes (!!!), as the license check routines doesn't even attempt to validate the data further - there is a serial as part of the license but it's just cosmetic. What this program DOES check for is for a couple specific registered user name values: "Sofsource Inc." and "COSMI Corp" - both of these switch from "Registered" to "Retail" license mode, and the latter one renames the product to "Las Vegas Super Casino", so I guess those were used for a sublicensed version for specific customers.

    Oh, and the very same license file unlocks BOTH products, yet they were sold separately back then!
    tomman Heads: obvious copyright/intellectual property infringements over (mostly) abandoned software motivated due to extreme boredom induced by a potentially lethal (non-computer) virus.

    Tails: OllyDbg and "what the hell is a "JMP SHORT?".

    Weirdest coin toss ever. Make your pick, you still lose :D
    Kawaoneechan There are supposed to be winners here? 😮
    CaptainJistuce
    Posted by Kawa
    Some people spend the apocalypse making sourdough bread.

    Others... others crack long-forgotten ActiveX controls.
    And who can say which are the winners?
    Kawaoneechan Some people spend the apocalypse making sourdough bread.

    Others... others crack long-forgotten ActiveX controls.
    tomman For BACCLOAD and KENOLOAD, I had no option but to install them on a XP VM (thankfully they're self-contained). Both apps are from the same dev, and use exactly the same set of VBXs:

    - FXTools/VB 2.x (FXIMG210.VBX/FXLBL210.VBX): Well, thanks to Kawa, my IDE is ready for that pile of 32-bit suck... but not my body :/

    - Crescent QuickPak (CSGROUP.VBX): This bunch of widgets (because everybody and his dog just had to make Yet Another SSCommand clone among a pile of ugly widgets) not only made it to the 32-bit land, but also has survived all those years as a retail product, albeit as an unsupported one... yet Sax Software (their current publisher) still wants $800 as a "legacy tax" - you pay the price of a nice hi-end cellphone in exchange for a 4MB installer, a regkey, and nothing else so you can keep those Win16-smelly VB6 apps trucking along until the apocalypse. While the installer is readily available for everyone, you need that very expensive regkey... or spend a hour or two with these tools, your favorite debugger, and your handy hexeditor to strategically place that couple of unconditional JMPs on the installer to skip this enterprisey nonsense :P

    - MediaArchitects MediaKnife (MKTLS16.VBX): This is a sad tale - apparently moving onto the 32-bit arena ended bankrupting those folks faster than light, and while Olympus picked most of the pieces (just to sell them back to their successor company years later... only to get dumped at some German shop even later), MediaKnife had a swift, merciless death. All we have left is a 32-bit trial version, but that one is not crippled at all - it just has a nagscreen which is trivial to neuter if you really want to. And yes, some of their widgets have horrible drawing performance on their 32-bit versions.

    What the hell am I doing with my life!? I should be playing videogames or watching porn, not cracking forgotten ActiveX controls :D
    DAMN YOU, CHINA!
    tomman Found some shareware using a very early version of Sheridan 3D controls: SHERDN01.VBX only contains SSCommand and our dreaded SSPanel, nothing else.

    This VBX refuses to load on VB3, most likely because it lacks design-time licenses (although Process Monitor doesn't show any traces of license file related activity?), so it has to be fooled. But DoDi's tools created unusable files instead (even VBPDIS3 errored out and output broken code). During one of my trials, by accident I made a definition file for the standard THREED.VBX instead, but that one actually worked! (the decompiler complained, but the output code had correct properties and events). No, you can't swap SHERDN01.VBX with THREED.VBX without recompiling - apps will crash.

    Before loading on VB6, make sure to replace the VBX references, as the default VBX conversion statements know nothing about this dinosaur Sheridan.
    Kawaoneechan ... what have I done 😟
    tomman Awesome! You rock, thanks for that~~

    (Idea for an Archive collection: an old/discontinued/abandoned VBX/ActiveX control collection, complete with regkeys where applicable.)

    And with all requirements set, let's "revive" Yet Another VB3 Card Game Shareware:

    Solator Suite turned out into yet another small nightmare, due to the following:

    - FXTools. Oh GOD DAMN IT, the 32-bit ActiveX version performance is just AWFUL! They claim to be multithreaded, yet their fancy "FX" crap runs in the same thread as the rest of your UI. Even worse: the animations lock up your UI, HARD. All while eating a entire CPU core for Powerpoint-esque effects the real PowerPoint could ace on a P5 with minimal CPU load. The worst offender is the About dialog, as it has both a FXImage and a FXText control, the latter cycling colors driven on a timer. Open that dialog on the 16-bit version and everything is kosher. Do the same on 32-bit, and most likely you will end yourself clicking like mad the OK button while looking for the task killer because the UI task simply had no time to process UI messages until the animations finished! (If you were looping them, well... it's the task killer or nothing). These controls do feature a "Multitask" feature that supposedly makes them behave if you need to perform other tasks (according to the documentation, which is quite terrible for a product that retailed for FOUR HUNDRED AMERICAN MONEY UNITS FROM 1999!), but it does nothing here. The 16-bit VBXs are good citizens while the 32-bit OCXs are a bunch of CPU-starving rebels. Even the sample applications shipped with FXTools 5 exhibit the very same flaws!

    - Not to be outdone by future FXTools shenanigans, this app also commits some cardinal sins. It has a nagscreen, sure... but I'll now call it The Nagscreen From Hell. It is supposed to play a "welcome" audio effect when dismissed, but due to possible race conditions within their bunch of timers and the way different VB versions initialize forms (I guess), it tries to play said sound effects from an undefined (empty) path stored in a global variable... which was supposed to be populated from the main form Load event handler. All this worked fine on VB3 because VB3 did things its way, but fail to work on VB6. Because calling App.Path was MUCHO MUY EXPENSIVE back in 1995, therefore the need for a useless global variable I guess? Oh, and due to its timer extravaganza, one of those try to focus a button on application exit... a button that it's not shown at this state! All because the exit menu handler (but NOT the Form_Unload one) reenables said specific timer which should not be used here.

    After realizing that 32-bit FXTools performance had no hope of improvement (now I get why Pegasus buried the product as soon as they could instead of improving it, yet their helpfile tried to sell me their amazing proprietary ePIC image file format with a ungoogleable filename, now long forgotten), dealing with The Nagscreen From Hell, getting rid of MHTimers (that for some reason BeCubed installer didn't created a VBX conversion entry) I was done with this one. Regkeys are simple, they encode nothing, but entering yours means dealing with a sloooooow MHIntInput control that may lead you to an endless loop of "Invalid Registration Key" messages. Yay.

    This application features MH3DMenu, a rather horrible way to skin standard menubars. These menus were full of glitches under NTVDM (including missing menu images replaced with a generic window bitmap), and I guess MicroHelp gave up trying to get that mess ported to Win32, so that's the only legacy MicroHelp control for which you will find no replacement on OLETools. Fortunately this breaks nothing, your app will fall back to plain Win32 menubars instead as this seemingly was one of those "no-code" magic VBXs. By the way, the FXTools 5 installer only creates VBX conversion entries for v4 VBXs, but this app used the ancient v1.4 controls, so you will need to address that before importing the VB3 project on VB6 to prevent further carnage. Either copy the entries for newer VBXs on VB.INI, or rename the actual VBX files and edit the VB3 .MAK project (for whatever reason, VB6 will get very angry if the original VBXs aren't there!)
    Kawaoneechan FXGOLD5.zip, extracted from the ISO.
    tomman In the meanwhile, found a solution for VideoSoft VBX (VSElastic/VSIndexTab) consumers: as you know, like pretty much every 3rd-party VBX/OCX control maker, VideoSoft went the Mergers & Acquisitions way through these decades: first merged with Apex to create ComponentOne, which eventually became Grapefruit.

    They still develop those controls (mostly their .NET successors, but they also have Win64 OCXs - TIL those are a thing too!), although you're now supposed to use their fancy net installer to download dozens of megabytes of demoversion junk or whatever. Luckily for us, they left their time machine parked at http://download.componentone.com/pub/oldstuff/ - for this case we can grab VS6OCX.ZIP... or even better, VS6OCXESD.ZIP, as that one contains the license registration program which allows you to properly register your design-time licenses (in the case of VideoSoft controls, you CAN use those without a license, but they will nag you). All you need is to find a regcode out there (I had luck with a code starting with "0666-" from an ancient FATIGUE.NFO file)

    Unfortunately, the VBX design-time licenses have been lost to the mists of time, but at least the nagscreen is a minor annoyance, and sometimes it may not even show at all! Having all pieces of this puzzle in place, I decided to revisit one of the few VSVBX.VBX sharewares, some Spainard phone agenda proggy (AGEWIN.ZIP).

    I had already built a more normal version using PictureBoxes and MS tabbed controls, but those VSElastic panels did some Magic™ (like automatically resizing everything when the form is resized) which could not be replicated with those standard controls, but I started from scratch anyway. Apparently DoDi's tools couldn't create a proper control definition file for this one (I got the .300/.SEG pair, but VBPDIS3.EXE complained anyway), so I ended with broken property and event references. Plus, the vsOCX installer wrote a bogus VBX upgrade entry on VB.INI, referencing both a non-existing typelib GUID and the wrong OCX (VSOCX32 instead of VSOCX6) - maybe those were for previous versions? A quick check at OLE Viewer got me the correct values, but even then VB6 bitched loudly and turned the Magic™ into PictureBoxes anyway!

    Looks like VideoSoft had changed the control name prefixes from "VideoSoftXXXXX" to "vsXXXXX" sometime after upgrading to ActiveX, so it's time to call your favorite texteditor, and fix all those references. But VB6 STILL refuses to load the controls! Fuck you VB, what do you want from me!?

    Oh, it wants the class library prefix too - the correct references would be "vsOcx6LibCtl.vsXXXXX", and sure enough, the forms loaded correctly this time. All I had to do was to fix the broken property references (the uncompilable P?00D0 would become CurrTab, for example) and broken event handlers ("Tab1_evt0000Something" would be actually "Tab1_Click").

    Sidenotes:
    - This proggy used SendMessage with EM_SETREADONLY to, well, lock textboxes read-only because VB3 didn't had the Locked property yet.
    - This shareware version is limited to 3 records per letter... except that it verifies if the limit has been exceeded BEFORE creating a new record, thus actually allowing for 4 records per letter. Nice off-by-one error there :P
    - vsIndexTab is kinda quirky when on the IDE - you may end with a control with no tab initially selected (CurrTab = -1), which in this program leads to a nice runtime error because it tries to read the tab caption of a non-existing tab!
    - Speaking of tabs, this program doesn't even bother using the TabCaption property array (currentTabCaption = Tab1.TabCaption(Tab1.CurrTab)) - no, that's too EASY MODO in Spain, it seems! Instead this guy exploited the fact that on vsIndexTab, the Caption property returns the caption for ALL tabs in the form of "Tab1|Tab2|Tab3|...|LastTab". Since each tab had a single-letter caption in this app, he used Mid$ for extracting the caption instead. WTF!?
    Kawaoneechan Note to self: halp Tom in the morning.
    tomman Found a game using a whooping total of 10 VBXs: Solator Suite (SOLATOR.ZIP):

    - Common Dialogs (CMDIALOG)
    - MCI
    - SIX random MicroHelp VBXs (MHGCMD, MHGLBL, MHGMEN, MHGININT, MHTIP, MHTM200)
    - ImageFX FXTOOLS/VB (FXIMG140, FXLBL140)
    ... plus QCARD.DLL, because card games need a card API, of course!

    That 592KiB downluad surely was packed to the brim with VBX hell!

    CMDIALOG/MCI are standard VB stuff. I already got the MicroHelp (BeCubed) bits covered. QCARD as we know has a 32-bit version which works and it's not impossible to download nowadays. Which leaves me with the FXTools bits - here is what I've found so far:

    - ImageFX became Pegasus Software, which became Pegasus Imaging, which years later became Accusoft. The latter two specialize in medical/legal imaging solutions.
    - FXTools went 32-bit as early as 1996. The last 16-bit version was FXTools Professional 4, while FXTools Gold 5 was the end of the road for the product. It never had a .NET version.
    - Pegasus Imaging had stopped supporting FXTools as early as 2003, according to the Archive. They had removed all and any mentions of the product from their product and support pages!
    - These controls were pricey - a FXTools Gold 5 license used to cost $399 in '00 dollars!
    - There was a trial version available for download on their site, but it was locked behind a questionnaire form. Unfortunately the Archive couldn't deal with those, so no HTTP links survive. They also had a FTP server (to which certain download sites of questionable reputation try to redirect if you're lucky), but the Archive don't crawl those either!
    - Trial version filename is fxgold5.exe, ~4.1MiB
    - Amazingly enough, regkeys (and even a keygen) can be easily found (virus-free, even!) - these are supposed to unlock the trial version.
    - As for the 16-bit VBXs, DoDi's full version ships with another tool you can use to work around licensing restrictions, VBXFOOL.EXE. That's effectively a crack tool which "fooled" VBXs that they weren't working in design mode, yet you could freely use them like they were licensed! VBXFOOL.EXE successfully created "fooled" copies of the 16-bit FXTOOLS/VB controls.

    Apparently the sole surviving source for those is an old warez CD-ROM compilation (!!!) which someone uploaded at the Archive (since when they do allow those?!?!?!). While it's cool to preserve old scene shit, the Archive viewers can't look into .ISO files, and I can't exactly afford the 633MiB download with a metered 3G stick that only lets me access half the Internet most of the times, so consider this a HALP request, pretty please? I only need that 4MiB trial version installer...
    tomman ...and for the final part of this PsL '96 CDROM chapter:

    - RR2_96.ZIP: Welcome to Straight Line Zone... well, almost. Absolutely no API Declares at all! I just had to fix up a few SSFrames, rename a couple Images (apparently VB3 would let name your controls "In" and "Out", but not VB6) and that was it. Too bad this "rat racing gambling simulator" sucks. Freeware, so nothing to crack.

    - STICKEM20.ZIP: Same dev as Tower Solitaire (of which I'm going to write later), this is a sort of board game where you build shapes out of sticks, trying to match shape cards. The only gotcha is a "custom" VBX which turned out to not be custom at all: "stickems.vbx" is nothing but good ol' SPIN.VBX with another filename, but that's enough to fool DoDi's (and the VB IDE!). The solution is easy as pie: on DoDi's dir, copy SPIN.300 to STICKEMS.300. Decompile, then edit the .MAK file to replace STICKEMS.VBX to SPIN.VBX. Now you can import the project on VB6. But even after the mandatory API upgrades and fixes, the game will still refuse to run! That's because it expect to load shape definitions from its INI file (STICKEM.INI). "What definitions!?", you say. Look again at your ZIP file: this game ships with an installer - SETUP.INF contains the juicy bits we need: just copy all lines preceded with "I=" to a new text file, remove said "I=" prefixes, save to STICKEM.INI in your binary/project folder, and you're good to go. There is also a hidden debug menu that can be enabled via the INI file, but sadly it's stubbed out on the release binaries (the code is simply not there). Regkeys are... unique? You don't enter yours through the program, but on the INI file!

    - TOWER20.ZIP: That's an upgraded Tower Solitaire, of which I already did an earlier version from the CD Ware disc (even ported it to WinCards despite it not using any external card DLL/VBX - I couldn't stand its broken card images), so I left it aside for now. I'm a sucker for pyramid solitaire, so I would be wasting the entire week by RE'ing, fixing and porting this version too :D

    - TTRON.ZIP: Another Stephen F. Naninni special! I know nothing about old Hollywood, and this is a demo version that ships with hardcoded quiz contents, so I promptly got bored with this one. As you may be aware from his Lotto Picks "game", this guy has a knack for hidden key sequences whose only purpose in life are a) ensuring you're running an "Authentic" Stephen F. Naninni executable, b) printing the Stephen F. Naninni name on a fancy marquee, and c) providing the user with an easy way to quit Windows once you get bored with any of the Stephen F. Naninni applications.

    - Just for kicks, I loaded the VBPDIS3.EXE decompiler on the "decompiled" (and now "unlocked") VBDIS3 builds, and sure enough, I was able to decompile it. Since DoDi was wise enough to dogfood his "protectors", the forms and control names are now lost forever (so everything is now "controlXX"), but that level of "protection" is a joke anyway. Unfortunately the rebuilt decompiler has the string constants bug, so I now have to figure out how to repair those before attempting to build this thing.

    I've run out of executables again, but now that I know how to deal with custom VBXs I guess I should revisit those .ZIPs with MicroHelp/BeCubed VBXs, now that I have access to the licensed versions of those.
    tomman ...and more fun:

    - KENOLOAD.ZIP: It's an installer which I haven't bothered unpacking, so meh.

    - KONO20.ZIP: Once again, an unsupported VBX - CNTL.VBX. Apparently this one was a sample control made by Microsoft, implementing a simple counter widget. Since it was so simple, I did made my own UserControl replacement. Man, I forgot how terrible was to write UserControls on VB (including its nasty ActiveX Control Interface wizard that loved to crash on my PC until I found that it was due to TLBINF32.DLL that needed to be re-registered. Even then, the wizard was still a pile of suck). It doesn't exactly match the original, but it's Close Enough™ to fool the program and let me play the game. Overly simplified board game that it's still a bitch. Has a very weird registration system that tries to convince you to earn money by getting other people to register the application, and it's unclear if I even got this thing registered...

    - LOTTO1.ZIP: A slightly newer version of the same LOTTO1.ZIP from the CD WARE disc. Same boring shit. The guy changed the hidden key combos and added some new ones, whose only purpose in life are to ensure you're running an authentic executable... and to display the author name in a PictureBox. Oh, and Ctrl+Shift+W on the About dialog let's you... exit Windows. Why?!

    - LUCKY41.ZIP: Exactly the same as CHERRY41/DYNA41 (and it's VB4/32-bit version is 95LUCK41.ZIP), down to the very same text size bugs and hardcoded regkeys! But no problemo, you could just pay $60 for three binaries of the same reskinned game back in 1996! This guy must be working now doing FIFA games.

    - PHHUNT.ZIP: Lame Duck Hunt clone (sans the Zapper), with photorealistic graphics, and nearly unplayable on modern hardware because your rifle moves way too fast. The only workaround I was able to slow down the game to nearly playable speeds (without messing too much with the game logic and/or stall the game too much) was to insert a "Sleep 10" statement just after a DoEvents in the cmdStart_Click() handler. Quoting the great Beavis: "This game sucks!". Regkey are unique. This one relies on cpuid16.dll (seems to be some Intel reference libs, also available for Win32) to tell on which CPU you're running the game, most likely to adjust performance on slower boxes (it explicitly checks for 386, 486, Pentium and Pentium Pro or later, and increases some variable if it detects the two former ones). Thankfully there is no need to locate cpuid32.dll, as the CPUID functionality is now present on the GetSystemInfo Win32 API function.

    - PKDICE.ZIP: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHH!!!!
    FUCK
    VISUAL
    BASIC
    FOREVER!


    Quick, what do you see wrong in this code?
    Private Declare Function CreateBitmap Lib "gdi32" (ByVal nWidth As Long, ByVal nHeight As Long, ByVal nPlanes As Long, ByVal nBitCount As Long, lpBits As Any) As Long
    ' ...snip...
    gMask = CreateBitmap(picTable.ScaleWidth, picTable.ScaleWidth, 1&, 1&, 0&)

    I must explain: this game uses ye olde "let's fake transparency with mask bitmaps and temporary hDC hax" trick in order to draw transparent sprites on screen (in this game: dice and a cup for them), because true transparent blitting wouldn't appear until Windows 98/2000 (TransparentBlt). This looks kinda complex, but it's actually not that hardcore: you create a couple device contexts in memory, associate one to a monochrome bitmap (which will be your mask), and with some BitBlt raster ops magic (SRCINVERT/SRCAND), you will be able to achieve transparent sprites.

    ...or not.
    Everything worked fine on the original VB3 executable (even on the dissasembly when loaded and fixed to run on VB3), but on VB6 all I got were opaque sprites (dice and cup with white corners) because FUCK YOU THAT'S WHY. This fucking piece of shit got me stuck for THREE GODDAMNED DAYS where I tried everything short of rebooting my PC, reinstalling Visual Studio, or nuking it from orbit. Apparently that CreateBitmap was returning NULL... but not when trying to create very small bitmaps (<~100x100px). Checked everything, debugged every BitBlt function, tried to ask Windows why the null handle (on VB forget about GetLastError - use Err.LastDLLError instead!) but got no answer, checked ScaleMode settings (in one form it was set to User instead of pixel/twip, but that didn't mattered anyway), even compared it to sample code from other devs doing the same (it was pretty much the same stuff)...

    Long short story: lpBits (that is, your palette data) is not supposed to be NULL, except for monochrome (1-bit) bitmaps, where it HAS to be NULL. That's why the 0& on the VB API call... except that for some motherfucking reason that I can't get in the name of Kemeny and Kurtz (the gods of BASIC for those of you guys out there at better languages), VB was instead telling Windows the ADDRESS to that fucking zero, instead of a null pointer (because of course there are no pointers in BASIC!). This fuckery SOMEHOW worked if all you wanted was a icon-sized mask, but once you wanted larger bitmaps, all bets were off. The solution?
    gMask = CreateBitmap(picTable.ScaleWidth, picTable.ScaleWidth, 1&, 1&, ByVal 0&)

    You have to explicitely tell VB that you want to pass that zero by value, as you're indeed passing the address of zero, that is, A FUCKING NULL POINTER!
    There you have, transparent sprites! And it took me three days of wandering around, trying to figure it out why Visual Basic and Windows were misleading me so hard.
    Screwtape Aw man, MSGBLAST.VBX, there's a blast from the past. If I recall correctly, it was pretty easy to make a VB app send custom Windows messages to any other window, but any incoming message that didn't exactly map to a pre-defined function was dropped. For example, WM_CLICK messages caused the VB runtime to invoke control's OnClick subroutine, but the Win3.1 drag-and-drop messages didn't have standard VB subroutines to handle them, so you couldn't drag-and-drop files from File Manager onto a VB app.

    MSGBLAST was a way to hook into otherwise-ignored messages - I think it gave you a generic "message arrived" subroutine that included the message number as a parameter, and let you do whatever you liked. It was a nice half-way point between the tidy and manicured garded of VB, and writing your own WinMain function in C.

    Of course, you could still get pretty far without MSGBLAST if you knew about about the state machine of Windows messages. I remember having my tiny teenaged mind blown when somebody showed my how to make a custom fake titlebar that could still move the window around. I assumed it would be a bunch of work, involving having to poll the cursor position, track movement, and repeatedly set the window's position properties, but it was actually much simpler: in the VB "OnMouseDown" handler for the widget, you send the widget a fake WM_LBUTTONUP message (so it assumes its no longer being clicked), then you send the window a fake WM_NCLBUTTONDOWN message (so it assumes the title-bar is being clicked) and the Windows default message handling does everything else for you.
      Main » Programming » Resurrecting Visual Basic 3 shareware in VB6 » New reply
      Yes, it's an ad.