0 users browsing Programming. | 1 bot
| tomman |
Posted on 20-05-08, 14:41
|
|
Dinosaur
 Post: #681 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
As a continuation of this, I'll keep this as a log of my newfound pastime during these lockdown (and limited connectivity) times. Let's recap: - The optimal OS for doing this is XP (with SP3!). Spinning up a XP VM nowadays is a no-brainer, so do it! Installing anything pre-.NET on modern Windows versions is a recipe for pain (sure, there are ways to do so, but even then AVOID PAIN - a VM is more comfortable anyway). Plus you also need to install VB3 side by side, so you need NTVDM which is for 32-bit SKUs only! - If you actually want to install VB3 the old-fashioned way, install it first! That's because the installer is going to take over some file associations that are shared with VB6. VB3 works fine from a portable version anyway, and those are the ones you're most likely to find online. Doesn't matter if you're using Standard or Professional - just make sure to not miss any of the important MS and 3rd-party VBXs shipped with those (THREED.VBX and friends). What I did was to take a snapshot at one of my XP VMs, install VB3 Pro (sans Crystal Reports and the 16-bit database junk), figure out what files were placed at the 16-bit %WinDir%\SYSTEM, copy those to the VB3 root dir, copy VB.INI from %WinDir%, cleanup, zip that, copy out of the VM, and rollback to the previous snapshot. - Install VB3 first (if you want), then VB6, then SP6 (they're accumulative so you don't need to install any previous SP), then KB2708437 and KB3096896 (without those, common controls OCXs may fail to load on VB6 IDE). Reboot. Don't forget to grab the old VB4 32-bit OCXs from your VB/VS6 discs (depending on your particular version it may or may not be on Disc 1 - on VS6 Enterprise they're on disc 3). Or if your dog ate your MSDN subscription, yank those from here. Copy them to %WinSysDir%, regsvr32 'em, and install the design-time licenses from vbctrls.reg (this last step is the most important one!) - On your target seutup, VB.INI must go on %WinDir%. But since VB6 also uses that file for compatibility reasons, you simply can't replace it! (it stores VBX->OCX mappings for the common ancient VBXs to the 32-bit land), so just merge both files contents, and set the VB3 path accordingly to your setup. - There are several versions of DoDi's dissasembler out there (including the 32-bit "port" from the dissasembly). You want ALL OF THEM, because DoDi's is a very fickle piece of code. Some versions will choke with certain apps (more on that later), forcing you to try with other releases until you get code you can use. Oh, remember to edit FRMS2TXT settings to match your system locale! (dialog hotkeys) - Since we're going to deal with 16-bit crud, it also means DOS restrictions are enforced, that is, 8.3 filenames and path length limits. Avoid too nested folders with long names for your dissasemblies AND tools! That's all for setup for now. Next posts will talk about getting your hands dirty with Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-08, 15:19
|
|
Dinosaur
Post: #682 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Time for some Win32 porting issues you must be aware when performing those revivals! Almost every Visual Basic application ever made has to break its VB runtime cage and talk to the underlying Windows OS to actually get shit done (from painting bitmaps FAST to crashing with bad pointers REAL FAST). Leaving aside the fact DoDi's dissasemblies rarely compile right away, you must be very careful when dealing with the Windows API when porting code. - Have a good API viewer installed, and be careful with API definitions, as they're often full of errors! (in other words, don't use the Win32 API viewer that ships with VB!). I use ApiViewer 2004, but that one is already obsolete and deprecated :/ - DoDi's can't recover the original names for Subs, Functions, variables, and declared API calls - for those you end with "extfnF00D" names, but luckily the alias names (that is, the actual names exported from the real DLLs) are recovered by the dissasembler. Search and replace those first, THEN replace the API calls with their proper Win32 equivalents. - The most important thing you gotta take care of are data types. A lot of stuff that were 16-bit integers are now 32-bit longs, including parameters and return values from API calls. Neglecting to follow this rule is the #1 way to get crashes and runtime errors! (error 6, Overflow, being the most common one). The rule of thumb is that if you want something from Windows, you must use the proper pointer size for the architecture (for performance reasons), and on 32-bit those are Longs! Watch out for things like window handles (hWnd), device context handles (hDC), and pointers (anything ByRef, which is the default on VB) - While most API calls are straight library swaps ("kernel" -> "kernel32") and Integer->Long promotions, there are a few APIs that didn't survived the 32-bit transition: GetWinFlags, GetFreeSpace (system info APIs, replaced with GetSystemInfo/GetVersionEx and GlobalMemoryStatus), some sound APIs (for which there are no replacements, so if your app made beeps and boops other than with Beep/sndPlaySound/MCI, you're out of luck), some APIs for which only their XxxDoSomethingEx versions remain, among others. There are some sites with more or less complete lists and suitable replacements, so you will need to invest some time researching and making compatibility modules. - hmemcpy now lives as CopyMemory (AKA RtlMoveMemory), with basically the same syntax. - If your app used GlobalSomething memory management APIs, it's time to get rid of them. While most of those are still there on Win32, they're solely for Win16 compatibility, and even back in 1995 Microsoft was discouraging their use on new 32-bit software! Plus they're excellent to get mysterious segfaults (with not even the "Your application has closed" crash dialogs!). Often, a suitable replacement are native VB byte arrays. - Most constants are the same between Win16 and Win32, but there are some exceptions. This matters because DoDi's can't recover the original constant names as defined by the original programmer, and it's well worth the effort to decipher those to get stuff properly working and not crashing. As an example, while porting some Solitaire game I found myself scratching my head because I couldn't find what message was &H40A. Looking at the Win16 API definitions shipped with VB3, any message code over &H400 are user-defined (WM_USER), but some widgets often used message codes on those ranges. Long short story: this specific piece of code was SendMessage'ing a textbox to learn how many lines of text it had to adjust its height accordingly (something that you can't do natively, not even on VB6 as the TextBox control lacks a "LineCount" method!). Turns out that the message was EM_GETLINECOUNT, which was (WM_USER + 10) on Win16, but moved to &HBA (that is, an actual reserved system message code) on Win32! So yeah, you gotta git gud on both Win16 and Win32 API! - Speaking about constants, some API constants are now defined at the standard VB/VBA/VBRUN typelibs that each and every new VB6 app references by default. This comes handy for things like any of the GDI's blitting functions, as VB uses the exact same raster op constants (the most popular one being SRCCOPY aka vbSrcCopy AKA &HCC0020). Most games will call BitBlt to draw stuff as it is FAST, so watch out! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-08, 16:20 (revision 1)
|
|
Dinosaur
Post: #683 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
It's third-party component time! AKA VBX/OCX hell. If your application uses VBXs other than (32-bit replacement in parenthesis): - ANIBUTTON.VBX (anibtn32.ocx) - CMDIALOG.VBX (comdlg32.ocx) - CRYSTAL.VBX (whatever 32-bit OCX ships with Crystal Reports nowadays) - GAUGE.VBX (gauge32.ocx) - GRAPH.VBX (graph32.ocx and a couple helper libs/EXEs) - GRID.VBX (grid32.ocx) - KEYSTAT.VBX (keysta32.ocx) - MCI.VBX (mci32.ocx) - MSCOMM.VBX (mscomm32.ocx) - MSMAPI.VBX (msmapi32.ocx) - MSMASKED.VBX (msmask32.ocx) - MSOLE2.VBX (replaced by 32-bit VB's built-in OLE control) - MSOUTLIN.VBX (msoutl32.ocx) - PENCTRL.VBX (no replacement!!!) - PICCLIP.VBX (picclp32.ocx) - SPIN.VBX (spin32.ocx) - THREED.VBX (threed32.ocx) - and the stock VB controls ...then forget it - you won't even be able to get that application properly dissasembled most of the times, due to the following: 1) DoDi's relies on control definition files (.300 files) to know where to look for properties and methods referenced in code. The decompiler ships with definition for the stock control set as shipped on VB3 Professional, but for other 3rd-party VBXs you had to make your own control definition files. While DoDi's also has tools for that (VBCTRL2/VBCTRL3.EXE being the older versions, and a template VB3 project that references a DODIVB.DLL being the new, recommended way to create said reference files), I've been unable to get any of those to generate useable .300 files: - VBCTRL3.EXE generates a mostly empty .300 file whose only contents are the VBX path (!!!) - the template VB3 project does generate a .300 file which references a .SEG file (which is created too, and looks like the real deal), but no version of the decompiler will accept those. WTF!? 2) Even without the control definition files, you're still able to recover the forms (you do need to copy the original VBX to VB3 root dir), but you will end with broken, uncompilable (and possibly unfixable) code because DoDi's can't recover the original property/method names on code, only some made-up addresses. Some builds of DoDi's may crash or stall during dissasembly without proper definition files, or may output corrupt forms that VB3 won't be able to open. 3) Even if you manage to get past this apparently un-surmountable hurdle, there is the next brick wall: finding 32-bit replacement OCXs for those custom VBXs. While Sheridan, MicroHelp, VideoSoft et al made the jump, they're long gone, although some of their legacy still survives after two decades of mergers (for example, VideoSoft stuff now lives under ComponentOne by Grapecity, and I forgot who owns the carcass of Sheridan), your $15 shareware component made by some BBS-lurker nobody waiting for your check on the mail is certainly defunct, with no 32-bit exit strategy. Even for the commercial survivors, it's unlikely you're going to find anything but standalone OCX file lacking the design-time licenses (therefore unusable for us), and most of those have been unavailable for sale for at least a decade. Even pirating those looks tough simply because nobody cares nowadays! (maybe we would had better luck in 2002...) BUT! Maybe you're lucky and your VBX falls under the "can live without it" category. Or after a careful review, you've decided you can pick up the pieces and move ahead with something else (I had to do this with a phonebook application that used VideoSoft's vsVBX - I was able to replace tabs and VSElastic containers with Microsoft's Tab control and good ol' PictureBoxes). And there are some VBXs you can ignore and discard right away since they serve no useful purpose nowadays, like those "3D style" enablers (i.e.: VBCTL3D.VBX) which were very popular prior to Win95 launch. You can achieve the exact same result under VB6 by simply setting Appearance to 3D on forms and each applicable control, no code or control needed whatsoever, as "3D style" is now native to the platform. Plus you get visual styles under XP with some minimal extra work. Too bad Silly Valley pundits now consider that 3D is for dinosaurs and they're going assbackwards to Win16 flatness :/ Protip: if your form uses Sheridan's 3D controls, consider getting rid of them - replace everything you can with native VB widgets! They're ugly, they look out of place, you can't get documentation for those anymore, and they may have weird bugs (like SSRibbon spurious click events if you have several of them in the same form, which have bitten my ass in at least two separate apps). Too bad you can't set picture alignment on native VB buttons, which would be the sole legit use you can find for those nowadays... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-09, 00:19
|
|
Dinosaur
Post: #685 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Dear $15 shareware authors from 1995, I've got a message for you from the year 2020: If you're going to provide one single executable for both shareware and registered users, to be unlocked with a registration key, please make sure that the key you send to each paying customer is actually UNIQUE! Hardcoded keys are the textbook definition of lame. At least force software pirates to make an effort to come up with a keygen for your junk! With love, A random hacker from Soviet Venezuela that is digging in your abandoned software. PS: Please ensure that your key validation routines do sanitize your inputs! (As soneone that actually had to come up with a key validation algorithm for $PRODUCT at $FORMER_JOB, I must say that writing such code really sucks - if you're not a math wiz kid with a knack for weird formulas, it's very hard to come with inspiration to devise a key scheme that works and can't be readily guessed/bruteforced by casuals) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-09, 22:40
|
|
Dinosaur
Post: #687 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
It's pretty much clear for everybody in this world that Visual Basic was just not made for action games, so you won't be playing the next Mario/Sonic or AAAAAA++++ Call of Doomfields: New Duke made in VB6 anytime soon. Yet this didn't stopped people making games in VB since the dawn of the On Error GoTo Hell era. But, what kind of games would you be making on a tool which can't get pixels pushed to screen at acceptable framerates? Card games, of course! Remember, before DirectX and WinG, Windows was already made for Solitaire. Hell, it even shipped with a free deck of cards with each copy! But then, Microsoft never really documented how to use that native "WinCards API" (or maybe devs just didn't liked the default card designs by Susan Kare), so they got quite creative when picking a method to draw cards on screen (no pun intended): 1) Use the native "WinCard" API (CARDS.DLL) - So far, I've yet to find a 16-bit game that actually uses the native CARDS.DLL API - maybe nobody bothered RE'ing Solitaire back then? (FWIW the API is pretty much the same on both Win16 and Win32) - Even on Win32, if you're on Win9x/Me, for whatever reason MS included the 16-bit versions of most Windows accessories -games included-, which implies that you won't have the 32-bit CARDS.DLL, so no free cards for you! Unless you pirate it, get a waiver from MS (the guy from Hardcore Visual Basic did it, but he worked for MS back then!), or pull some nasty thunking tricks - Albeit officially undocumented (and gone as of Windows 7), the "WinCard" API is very easy to use - call the DLL initialize function (which will tell you the default card dimensions), tell which card to draw, a device context on where to draw, and some (X,Y) coordinates, and you're set. - On VB6 it can be very tricky sometimes to get the cards to actually show on screen due to changes on the painting routines on this version. Make sure to call the .Refresh method on whatever component/form you're painting! In some extreme cases (particularly when painting to PictureBoxes), neither Refresh nor AutoRedraw worked, but quickly toggling the Visible property did the trick. 2) Use a 3rd-party cards library/component - A somewhat popular lib was VBCARDS.DLL (aka "The Grinning Jack Deck", look for VBCARDS.ZIP), which I've found in use in at least two shareware games (Brigzee and CardShark Hearts). On this one, his developer choose a rather lazy way to paint cards: In other words: this library trashes your clipboard because this dev was too lazy to figure out how to BitBlt cards to picture boxes. - Of course there is no Win32 version for this thing, so I ended devising a "wrapper" to somehow emulate VBCARDS.DLL functionality over "WinCards". Still, changes to code are needed since we're no longer relying on the clipboard as a lame shared memory surface. 3) Bundle your own card deck: - Frees you from external dependencies... - ...but wastes precious RAM and disk space! Plus it makes design and coding more messy (your BitBlt calls must now consider two sets of x,y coordinates: where to paint your card AND where to locate the desired card from that massive PictureBox containing your deck. Hope you don't suck at math!) - By far, the most common method out there, sadly. On the flip side, some games use this to your advantage, letting you load your own card decks from external files (MeggieSoft Games line of rummy games are a good example) - I highly encourage you to migrate any of those games to the sanity of CARDS.DLL, if possible! A word of caution: CARDS.DLL "interleaves" suits (card 0 is Ace of Clubs, card 1 is Ace of Diamonds, card 2 is Ace of Hearts, ...), while most of those VB card games (including VBCARDS.DLL consumers) do not (Card 1 is Ace of Spades, card 2 is Deuce of Spades, card 3 is 3 of Spades, ...). Oh, and as you've noticed, BASIC arrays can (and often do) start at indexes other than zero, so be careful with off-by-one errors if you come from other (rigid) languages! Also: WinCards lack joker cards, so be prepared for that case too. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Screwtape |
Posted on 20-05-10, 04:21
|
|
Full mod
 Post: #397 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
So far, I've yet to find a 16-bit game that actually uses the native CARDS.DLL API - maybe nobody bothered RE'ing Solitaire back then? That first article you linked to says "As a result, even shareware card games like Forty Thieves, Canfield and Constitution were able to keep their file size down considerably by referencing a file that, due to its inclusion with every Windows installation, was guaranteed to be on the system." I assume those aren't 16-bit games, then? The ending of the words is ALMSIVI. |
| Kawaoneechan |
Posted on 20-05-10, 06:45
|
|
OBJECTION!!
 Post: #485 of 599 Since: 10-29-18 Last post: 195 days Last view: 8 hours |
I have studied the Solitaire source code. Did you know that it's made of three logical parts? There's cards.dll of course, but the game itself has one part for card games in general and one part on top of that for Solitaire. Which means that it and all those other card games that you'd find in the Entertainment Pack like Golf and such possibly reuse a significant amount of code that could've been in the DLL. |
| tomman |
Posted on 20-05-10, 13:50 (revision 1)
|
|
Dinosaur
Post: #688 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Posted by Screwtape For the context of the thread, I mean non-MS made shareware 16-bit, developed in VB3. Posted by Kawa Yes, there are articles out there claiming that CARDS.DLL contained core cardgame logic. That's blatantly false, and Microsoft should just have named the lib "Standard 52-card poker card deck", not "Entertainment Pack Card Helper DLL". Fun fact: the 32-bit CARDS.DLL is even older than Win95/NT4. You can even get a copy installed on your Win3.x setup if you install Win32s, which comes with FreeCell as an option / "test application". I just tested said DLL (dated September 16, 1994) on my XP box and amazingly It Just Works™, despite being 26-year, very early 32-bit code. FWIW, Wine also emulates CARDS.DLL, but only with two unique card backgrounds and no animations. The only change it had along these years was in Windows XP, where they replaced the lovely pixel art card backs by Susan Kare with some generic hi-color stock photos which really feel out of place in a card game, as none of the resemble actual card games. Oh, and this broke card animations: cdtAnimate is still there, and even the actual bitmap fragments to be animated for the original card backs are present in the DLL resources, but obviously they don't match their intended cards anymore. I'm told that MS just stubbed out that one, but I haven't tested. --- In other news, I've just found two of those random disk shareware authors that are still alive! - Scandere Software (now Zedlam Games): Apparently Cubix (and the rest of his supposedly "shareware apps that revolutionized shareware") are still there, but you can't readily buy those anymore (yet the guy takes donations while complaining that nobody pays for shareware). Oh, and his label branched into table games. - MeggieSoft Games: Their Rummy-related card games are still available for purchase, they still redistribute full demos, they still use Classic Visual Basic (but now with extra bloat, as their games now have shiny backgrounds and CAN TALK!), and their games are still receiving updates as of late 2019 (!!!). Kinda pricey, tho, but they still apparently honor regcodes from 1995 ("you buy a product, not a subscription"). Now that's trust and loyalty! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 20-05-10, 14:33
|
|
Tall, Dark and Bishōjo
Post: #486 of 599 Since: 10-29-18 Last post: 195 days Last view: 8 hours |
"you buy a product, not a subscription" That's a sentiment worth of some applause. 👏 |
| tomman |
Posted on 20-05-10, 15:14
|
|
Dinosaur
Post: #689 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Posted by Kawa From their registration page: Registration codes for the MeggieSoft Games are software usage licenses, not subscriptions. Once you have purchased a registration code for one of the games, you are granted unlimited and indefinite personal use of that game. Additionally, under our current licensing policies, MeggieSoft Games does not charge additional license fees for version updates. Too bad Personal Computer™ Applications are doomed in this "what's a computer?" cellphone age :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-12, 02:54 (revision 2)
|
|
Dinosaur
Post: #691 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Here is the class of "weird bugs" I've got when dealing with forms using Sheridan 3D controls: Note that most of the frame headers (these are SSFrame instances) have HUGE fonts, and no matter what you do, you can't get those frames to display with the proper, specified font sizes! (in this example, the intended font size is 8 for all of them) - Don't waste your time with VB font dialogs, not only your font size setting won't stick, they will default to some weirdass FRACTIONAL value (like 8,75 for a 9 setting!) - Can't workaround this in code either, because either VB or Sheridan is trying to outsmart you. - Switching Form ScaleMode doesn't achieve anything at all. Of course looking for this on $FAVORITE_SEARCH_ENGINE will lead to a whole load of nothingness - am I alone in this? BUT! If you add a NEW frame to your form, it actually obeys you?!  WHAT THE FLYING FUCK, SHERIDAN?!?!?! The fix is stupidly simple, yet it took me several days to figure it out: 1) Select the affected control 2) On the Properties pane, copy the current value for the component width 3) Use your mouse to horizontally shrink/enlarge the component width on the form designer. DO NOT edit the width on the Properties pane, it WILL NOT help towards our desired fix! 4) Notice that text size (probably) came back to what we wanted 5) Restore (paste) the original component width on the Properties pane (this time you CAN and MUST do it this way) 6) You may now change the font size using the Font property, do it in code, etc. You may even need to set the proper font size, as it could have changed unexpectedly, AGAIN. The result:  This bizarre bug affects: - Outline control - MS Grid control - ALL of Sheridan 3D controls, but SSFrame and SSPanel are the worst offenders. This doesn't seem to happen on VB3, so I can't really blame DoDi's - maybe it's some really weird issue between VB6 and those legacy 32-bit VBX replacements... Hope this serves you as a PSA: if your 32-bit VB3 port relies on those relics, consider getting rid of them, by replacing either with native VB widgets (which already are 3D by design!), or by more reliable ActiveX stuff (if you can afford it, AND can find someone willing to sell those legacy licenses to you!) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 20-05-12, 06:32
|
|
Watches you while you're sleeping
Post: #487 of 599 Since: 10-29-18 Last post: 195 days Last view: 8 hours |
So weird, so niche, so clearly explained... so unlikely to crop up for anyone else 😸 |
| tomman |
Posted on 20-05-12, 14:33
|
|
Dinosaur
Post: #692 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Posted by Kawa I was able to replicate it on a brand new fresh VB3 project, so clearly it's not the decompilers' fault: 1) Create a new VB3 project 2) Add a couple of SSFrames/SSPanels and some other stock VB components. Notice that in VB3, those fractional font sizes are among the default font sizes on the Properties window. 3) Save forms as text when saving project (VB6 will not load binary 16-bit VB forms because they never thought people would want to upgrade their 16-bit apps into the brave new 32-bit world) 4) Open the project on VB6. Watch how your just-created SSPanels and SSFrames now have HUGE captions! 5) Perform the fixes (resize affected controls). You may need to reset font sizes for some of them, even after resizing them. Can't really tell if it is a configuration-specific problem (bare metal XP SP3 with all official MS patches, even those after the EOL date, VS6 Enterprise SP6 with the couple post-SP6 VB6 control patches), or some weird VB6 bug with those legacy controls, but I now have a reliable way to trigger it. Worth a testing, if you have access to some old VB3 projects and VB6 + legacy OCXs. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 20-05-13, 12:25
|
|
Derpy is best pony
Post: #488 of 599 Since: 10-29-18 Last post: 195 days Last view: 8 hours |
Fraid all of my VB3 stuff is lost to the mists of time, and didn't use SSPanels and the like. |
| Screwtape |
Posted on 20-05-13, 13:48
|
|
Full mod
Post: #400 of 443 Since: 10-30-18 Last post: 1101 days Last view: 172 days |
Turns out I *do* have some of my old VB3 stuff lying around, namely a little always-on-top clock themed to look like a tool-tip. The documentation is super-cringey, so I'm not going to upload it, but I'm impressed at how polished I made it: - Choose a custom font, foreground colour, and background colour. - Automatically CAPITALISE text, or strip punctuation, in case you're using a crazy font that's missing glyphs. - A right-click menu that includes all the functionality you'd expect in Windows 3.1 (Move-with-keyboard, minimise, close, open Task Manager) along with custom menu items - A custom About dialog - A custom settings dialog, with a status-bar that displays a description of each control as it gets the keyboard focus - A Windows Help file, containing things like "Files included in this package", "installation & deinstallation", "How to use", a screenshot of the setup dialog that pops up a description of each control as you click on it, and a bunch of other stuff. Also, most of the help pages have a link that pops up the same information, but written in what my teenage self thought was a hilariously sarcastic tone of voice - If you focus the window and hit Ctrl-C, the current time is copied to the clipboard - Apparently, this app will *also* publishes the time for DDE clients to read, and the help file includes a Word 6.0 macro to insert the time into the current document - Like MS-DOS 6 (I think), if you hold Shift while it's starting, it ignores saved settings and resets to the defaults - Like Program Manager and File Manager, if you hold Shift while quitting, the settings are saved and the program does not quit It turns out, it mostly works in Wine - it can't launch Task Manager or move the window with the keyboard, the clipboard integration doesn't seem to function, but it's sitting happily in the corner of my screen and updating properly, I can drag it around, and I can use all the fancy fonts I have installed. There's one thing about it that disappoints me: the version number displayed in the About window is different from the version number in the Setup window, and the help file clearly hasn't been updated since the entire previous release. Ah well, too late to worry about it now. The ending of the words is ALMSIVI. |
| Kawaoneechan |
Posted on 20-05-13, 14:41
|
|
Brony
Post: #489 of 599 Since: 10-29-18 Last post: 195 days Last view: 8 hours |
Well, I'm impressed. |
| tomman |
Posted on 20-05-13, 16:29
|
|
Dinosaur
Post: #693 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
I tried running the VB3 IDE on Wine:It runs... and crashes as soon as I try to open a project :/ Dunno why - I tried running some demo app from the same shareware CDROM which was made in Multimedia Toolbook (another popular choice for multimedia crap back then), and that one didn't had problem bringing up an Open File dialog. But on that one, video playback (the thing was a SIGGRAPH '95 demo with a HUGE 116MB 320x240 Indeo video in all its '90s blocky and muddy splendor) does not play. The same app also works under XP NTVDM, but without audio. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-14, 17:50
|
|
Dinosaur
Post: #695 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Posted by Kawa Heh, I still keep my very first VB (and by extension, PC software) code somewhere in my ol' backup CD-Rs. Prior to that, my only experience making code for computers was with LogoWriter (and that was in 1997 because that was what our school computer labs had back then, I'm not THAT old!), and I would have to wait until ~2000 when I could get a mostly working PC at home. But then, I came to the joy of Visual Basic (and Windows in general) well after the brave new world of 32-bit had already been settled. My first VB was Visual Basic 5 Control Creation Edition, that ~10MB free download from MS back when they were trying to get everybody and his dog involved into the ActiveX control craze (mine came on some random computer magazine shareware CD). While VB5CCE was crippled in a couple key areas (couldn't build standalone EXEs, the Data control is disabled on this release), it was enough to get me interested into becoming a software developer. Then, I got my pirate VS6 Enterprise discs (which I still keep!), which came with a copy of VB6 which could actually make standalone EXEs! Then, I entered college in 2004, made a couple of class assignments on VB6, and promptly forgot about it when I got introduced to bigger, better, badder languages (except C, which I still hate to this day - only my stray pointers could make a Fedora Core 3 box halt And now, I've come full circle, back to where everything started 20 years ago... Seriously MS, now that you're willing to support the VB6 runtimes until (the cold death of the universe| Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-15, 15:52
|
|
Dinosaur
Post: #697 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
If you don't have '90s shareware CD-ROMs (or floppies) with VB3 stuff to play (or if you're like me and just ran out of interesting targets to decompile - man, that CD Ware disc was seriously damaged...), you can look for more vintage shareware here: http://cd.textfiles.com/ Or in the Internet Archive - look for PsL CD-ROMs! Good to see people archiving that early era of DOS/Windows shareware, too bad most full versions and regkeys are now lost forever (except for VB2/3 and perharps VB4 stuff!) Now I kinda regret about having trashed my early '00s magazine CD-ROMs, but then, things had turned to suck due to bloat back then (I'm certainly not going to miss Macromedia Director autorun menus which always froze or crashed my Deceleron!) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 20-05-16, 00:41 (revision 1)
|
|
Dinosaur
Post: #698 of 1316 Since: 10-30-18 Last post: 1 hour Last view: 1 hour |
Found another cards DLL which was used by a few VB3 shareware games back then: Stephen Murphy's QCARD.DLL. Amazingly enough, this guy DID took the leap into the 32-bit arena shortly after Win95 hit the shores, and thus QCARD32.DLL was born. Look for qcarddll.zip/qcard32.zip, those are the SDKs containing the DLL, documentation and sample code for C/Delphi/VB (including the Declare statements for the latter, which you WILL need!). This DLL is far more functional than VBCards.dll or good ol' WinCards (it even handles drag and drop), and the 32-bit DLL seems to behave properly under XP, which is nice considering that the 32-bit variant was seldom used (compared to its 16-bit counterpart) and its last release was sometime around late '96. Mind you, this is not going to save you from missing VBX->OCX upgrades, but at least It's Something™. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
