0 users browsing Programming. | 2 bots
| tomman |
Posted on 20-05-16, 15:46
|
|
Dinosaur
 Post: #700 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
DoDi also made a decompiler for VB4 (both 16 and 32-bit; this was the last VB release for which p-code was the only choice), but unlike the VB3 ones, this branch (which was also made in VB3, go figure) never went very far. Public (and decompiled!) builds are available, but my trials have been a disaster: I've been unable to get usable decompilations... or a decompilation at all. Tried with a couple 32-bit VB4 proggies (looks like VB4 wasn't a popular release at all, and I've yet to see a 16-bit VB4 EXE in the wild), but the decompiler choked with those, outputting only fragments of code and runtime errors. So much for that - let's stick to VB3 and doubling bit counts then. Go here: http://cd.textfiles.com/psl/pslv4nv07/WIN/GAMES/ (that's from the PsL Monthly #4-07, circa July '96) Download everything that says "requires VBRUN300" (take a look inside FILES.BBS for a complete listing - nearly a year after Win95 most new shareware was still 16-bit) Have fun! Or better, I'll have fun in your name, so here comes a log of what I've done so far. - APOLLO.ZIP: Nice recordings, confusing UI, maybe this is actually for NASA guys. Found a shitload of API calls, including a bunch of deprecated/long gone stuff (modules with over 15 Declare statements!). At first, I thought "oh boy...". But after I started replacing declarations and function names, I realized that almost ALL of the code in those modules was DEAD CODE that was left there to rot - from GDI drawing routines to Windows/system info stuff, this game used nothing of that, except for BitBlt, sndPlaySound, mciSendCommand, and INI file I/O stuff. After purging all that dead junk (looks like these were part of some utility routines shared among other stuff from the same developer), ended reducing module count from 13 down to 4. Audio files go under /audio/. Regkeys are unique. - BACCLOAD.ZIP: Self-extracting Setup executable - can't use it as is, need to find an unpacker first! - CALBRSTR.ZIP: Kinda lame Solitaire game. Oh joy, unsupported VBXs! And a QCARD.DLL consumer! The latter was trivial once I found that QCARDS32.DLL was a thing and kept API compatibility. The former... well, that was no fun. This game uses DBPUSH.VBX (a SSCommand clone with a couple extra features, like round buttons) and MSGBLAST.VBX (something to intercept Windows messages so you can do hardcore stuff, like - DYNA41.ZIP: Slot machine thingy AKA "I can't understand this thing so I hate it". Six Declare statements, but three of them were unused (you can easily tell those apart since DoDi will decompile them without parameters, but that's not a 100% foolproof method, as there are legit WinAPI calls without parameters: GetVersion, GetTickCount, ...). First the program crashed at startup with an Overflow error - turns out it was a call to TextWidth with a freakishly long text for a text scroller - the shareware version message was fine for VB3, but too long for VB6!? After trimming some spaces, I got past this, just to be hit with a weirdass yellow overlay that stumped me for like half an hour. That one turned out to be FontSize being set to String values instead of Singles ("8.75" instead of 8.75) - you may have gotten away with that on VB3, but VB6 most likely was using a string pointer, which translated to an absurdly HUGE font size. After ensuring that all font sizes on code were actual NUMBERS, this one was done. Hardcoded regkey - BOO! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-17, 01:50 (revision 2)
|
|
Dinosaur
Post: #701 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
The quest for dumb continues: - CHERRY41.ZIP: Same as DYNA41.ZIP - it's another slot machine game from the same dev, down to the same bugs (font sizes as strings, too long strings, 3 unused APIs, etc). Yes, the one and only regkey still is hardcoded. (95CHRY41.ZIP/95DYNA41.ZIP are their counterpart 32-bit VB4 versions, but I have no working VB4 compilers so meh) - FF13W103.ZIP: Another QCARDS consumer, yay~! Except that this one actually used an even older DLL with a couple methods that no longer exist in later releases, including the 32-bit version (IsCardVisible/SetCardVisible). Actually, the methods were just renamed (GetCardStatus/SetCardStatus), so search'n'replace and off you go. From the same dev of Four Seasons, this thing features a hardcoded regkey (lame!), sounds (including MIDIs, so mciSendString abuse), and another lame solitaire game that mocks at you as you suck. Sidenote: the decompiled build of DoDi's chokes HARD with executables featuring global string constants (it will generate corrupt MAIN.TXT files that not even VB3 will want to open!). Fixing those by hand is a PITA and can lead you to bugs, so use the older 16-bit decompiler for those instead. - FREEJACK.ZIP: Nothing to crack here as this one is a freeware Blackjack game from the same author as CALBRSTR.ZIP, but with a twist: instead of QCARDS, he went with a custom VBX from MicroHelp to draw cards: MHCardDeck (MHCD200.VBX plus two extra DLLs, talk about overkill). Since we have custom VBXs, this means I can't really decompile this thing and import it on VB6 free from corrupt code and replacement PictureBoxes... right? ...not this time! See, I had wrote a few posts earlier that DoDi's VBX tools wrote unusable control definition files for the STANDARD decompiler, VBDIS3.EXE (on which the decompiled rebuild is based off). But if you have the full retail version, you will notice that there is an extra decompiler EXE (VBPDIS3.EXE), which features a very different UI. This one WILL correctly use the .300/.SEG split definition files that you should create with the template VB3 project (VBXDES.MAK, forget that VBCTRLx.EXE ever existed), leading to a successful decompilation at the first try. Nice, I can get non-corrupt sources, including the correct event handler definitions and method/function calls for those pesky VBXs. But... this doesn't solve the fact that we still need replacement OCXs. Before busting out the WinCards-based UserControl replacement that I may or may not write (last time I wrote one, the A380 wasn't flying yet, cellphones lacked color displays unless you lived in Japan, and .NET was the dark storm cloud looming over the happy VB6 playgrounds), let's recap a bit of history about MicroHelp VBXs: originally named VBTools back in the dark 16-bit ages, through the path of mergers and acquisitions, VBTools landed at BeCubed, where they took the jump to 32-bit under the name of OLETools (and eventually .NETools, although MHCardDeck didn't made the cut). Those were still Licensed Retail Components™, and quite expensive ones (a license would cost you $300+, but given that such money would net you licenses for over 60 controls on top of a very ugly card deck in a 10MB installer, that's wasn't a bad deal at all back then). Fast forward to 2015, where BeCubed finally realized that you can't run ActiveX controls on cellphones, so they decided to close down forever, not without doing what any serious software company should do before turning off the lights: give away your products until the domain expired! Sweet~! And thanks to the magic of the Internet Archive, those 60+ controls (and its free license key) are now preserved forever, which is a big help for this lockdown-induced pastime. After replacing yet another BitBlt/sndPlaySound combo (and realizing that I CAN'T BLACKJACK EVEN IF MY LIFE DEPENDED ON IT!), I was done with this. Sidenote: sadly the installer for the 16-bit VBTools VBXs wasn't archived (but if you can find one, the generic serial code should work), but if you want to use those standalone VBXs on the VB3 IDE (if you're doing the same I'm doing, you MUST have those VBX working!), you need to provide your own license files (otherwise the VBXs won't load). But since those were simpler times, this Korean blog reveals how trivial is to generate them: just copy/paste a hardcoded string to a specific filename and you're done! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Screwtape |
Posted on 20-05-17, 04:50
|
|
Full mod
 Post: #401 of 443 Since: 10-30-18 Last post: 1108 days Last view: 179 days |
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. The ending of the words is ALMSIVI. |
| tomman |
Posted on 20-05-20, 02:30
|
|
Dinosaur
Post: #704 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
...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? 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? 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. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-24, 02:32
|
|
Dinosaur
Post: #709 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
...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. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-25, 23:29 (revision 1)
|
|
Dinosaur
Post: #710 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
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... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 20-05-25, 23:33
|
|
Ask me about SCI
 Post: #491 of 599 Since: 10-29-18 Last post: 202 days Last view: 2 hours |
Note to self: halp Tom in the morning. |
| tomman |
Posted on 20-05-26, 03:08 (revision 1)
|
|
Dinosaur
Post: #711 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
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!? Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 20-05-26, 12:24
|
|
Rated M for Manly
Post: #492 of 599 Since: 10-29-18 Last post: 202 days Last view: 2 hours |
FXGOLD5.zip, extracted from the ISO. |
| tomman |
Posted on 20-05-26, 19:02
|
|
Dinosaur
Post: #712 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
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!) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 20-05-26, 20:11
|
|
The Thirteenth Doctor
Post: #493 of 599 Since: 10-29-18 Last post: 202 days Last view: 2 hours |
... what have I done 😟 |
| tomman |
Posted on 20-05-26, 22:17
|
|
Dinosaur
Post: #713 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
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. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-28, 01:41 (revision 2)
|
|
Dinosaur
Post: #715 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
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! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 20-05-28, 10:53
|
|
Off-Model
Post: #496 of 599 Since: 10-29-18 Last post: 202 days Last view: 2 hours |
Some people spend the apocalypse making sourdough bread. Others... others crack long-forgotten ActiveX controls. |
| CaptainJistuce |
Posted on 20-05-29, 00:19
|
|
Custom title here
 Post: #876 of 1164 Since: 10-30-18 Last post: 70 days Last view: 6 hours |
Posted by KawaAnd who can say which are the winners? --- In UTF-16, where available. --- |
| Kawaoneechan |
Posted on 20-05-29, 15:07
|
|
Don't. Even. Blink.
Post: #497 of 599 Since: 10-29-18 Last post: 202 days Last view: 2 hours |
There are supposed to be winners here? 😮 |
| tomman |
Posted on 20-05-29, 15:21 (revision 1)
|
|
Dinosaur
Post: #716 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
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 Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-06-03, 17:58 (revision 4)
|
|
Dinosaur
Post: #721 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
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! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 20-06-03, 19:28
|
|
Rainbow Dash
Post: #499 of 599 Since: 10-29-18 Last post: 202 days Last view: 2 hours |
If anyone could go eat a bowl of fuck it was those companies, then. |
| tomman |
Posted on 20-06-08, 18:02
|
|
Dinosaur
Post: #722 of 1318 Since: 10-30-18 Last post: 3 days Last view: 1 hour |
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 Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
