tomman |
Posted on 20-05-08, 14:41 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #681 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #682 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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 in Resurrecting Visual Basic 3 shareware in VB6 (revision 1)
|
Dinosaur
Post: #683 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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-08, 20:17 in COVID-19 (or why 2020 will SUCK for a lifetime)
|
Dinosaur
Post: #684 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
Coronavirus Found In Men's SemenThe new coronavirus can persist in men's semen even after they have begun to recover, a finding that raises the possibility the virus could be sexually transmitted, Chinese researchers said Thursday. A team at Shangqiu Municipal Hospital tested 38 male patients treated there at the height of the pandemic in China, in January and February. About 16% of them had evidence of the coronavirus in their semen, the team reported in the journal JAMA Network Open. About a quarter of them were in the acute stage of infection and nearly 9% of them were recovering, the team reported. It's not a surprising finding. Many viruses can live in the male reproductive tract. Ebola and Zika virus were both found to spread in semen, sometimes months after a male patient had recovered. It's not yet clear if coronavirus can spread this way. Finding evidence of virus does not necessarily mean it's infectious. ... I don't want to live in this world anymore. Thaaaaaaaaaaanks, China. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 20-05-09, 00:19 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #685 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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, 18:58 in higan v107 released
|
Dinosaur
Post: #686 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
Posted by creaothceann https://byuu.org/posts/ares So basically, COVID-19 pretty much ruined But he can't just stay quiet, doing nothing inside an apartment, and desperate times call for desperate measures, I guess. Still wish luck for him, he really needs some. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 20-05-09, 22:40 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #687 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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™ |
tomman |
Posted on 20-05-10, 13:50 in Resurrecting Visual Basic 3 shareware in VB6 (revision 1)
|
Dinosaur
Post: #688 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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™ |
tomman |
Posted on 20-05-10, 15:14 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #689 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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-11, 16:47 in Where to put the bsnes folder and my games please?
|
Dinosaur
Post: #690 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
Remember that %ProgramFiles% (typically C:\Program Files or C:\Program Files (x86) on 64-bit Windows versions) is a protected directory, and normal unprivileged programs (of which bsnes is one) can't have write access to, unless running elevated (that is, as Administrator, which is usually a bad idea). Just put your bsnes folder on a common place (as an example: back when I used to play with my emulators under Windows, I had a separate partition solely for games, and "F:\emus\<system name>\<emulator name>\" was my choice for emulators), and put your ROMs somewhere else (say, a separate folder inside the same common dir, but NEVER mix ROMs with emulator folders, as this quickly gets messy AND makes updates difficult). Let the emulator take care of everything else, and don't forget to do periodic backups of your important stuff (ROMs, game saves, etc.) just in case. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 20-05-12, 02:54 in Resurrecting Visual Basic 3 shareware in VB6 (revision 2)
|
Dinosaur
Post: #691 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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™ |
tomman |
Posted on 20-05-12, 14:33 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #692 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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™ |
tomman |
Posted on 20-05-13, 16:29 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #693 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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, 16:13 in Stupid computer bullcrap we put up with. (revision 1)
|
Dinosaur
Post: #694 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
In this episode of the neverending War On 32-bit: a Xorg wants to kill AGP on Linux (at least for ATi and nVidia): https://www.phoronix.com/scan.php?page=news_item&px=AGP-Radeon-Nouveau-Drop-RFC https://lists.freedesktop.org/archives/dri-devel/2020-May/265527.html Or not, but his reasoning is "it has always been broken" (well, if you consider that AGP is as shoehorned over PCI like VLB was to ISA, it's true), "drivers have always resorted to quirks to prevent crashes" (but then, Linux never had solid, high-performance AGP drivers unlike other platforms), and "nobody we know have been using those GPUs in over 10 years" (completely neglecting the fact that there are computer users in third-world hellholes for which neither "cheap RPis" nor "$50 Dells you can get by dumpster diving" are realistic options at their reach, plus AMD kept making AGP GPUs for their integrators until 2011 or so - have you forgot the HD46x0?), so it's time to get rid of their very hackishy support for AGP in the Linux kernel, which would (supposedly) clean up some stuff. If you actually read the proposals, they're not even going to kill your AGP GPUs, only disable/ignore the bits that are AGP-specific, and your card would still work as a good ol' PCI device (as it have to do anyway, considering that it's mandatory by the standard). You would retain the dedicated port access and higher speeds, but gone would be things like GART. Outside x86, AGP has been even more patchy: due to piss-poor hardware implementation on PPC, AGP bits were disabled there two years ago. If this comes to fruition on x86 and those patches get merged into upstream, expect a performance hit on your retrobox, depending on how ancient is your GPU. R500 and later ATi GPUs on AMD are actually PCIe silicon behind a bridge chip (Rialto), and those have been cheating all those years, ignoring some AGP-specific bits, so I expect that the impact for those should be low or none. For older ATi GPUs or anything by nVidia, expect pain. If you were using anything else (*cough*VIA*cough*Intel*cough*), you should already be used to severe pain anyway (and those patches would not affect you anyway) If only those GPUs (and the underlying AGP subsystem) ever had proper drivers since back then... but I guess it's much easier to justify software bloat ("retroboxes should be running retrosoftware"... good luck installing Debian Sarge or Fedora Core 3 over the net nowadays) or terrible drivers (butbutbut muh limited resources! Also, OEMs hate people and anything not made by Microsoft) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 20-05-14, 17:50 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #695 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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-14, 19:27 in Monocultures in Linux and browsers (formerly "Windows 10")
|
Dinosaur
Post: #696 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
In the next episode of "War On 32-Bit": Micro-Soft is phasing out 32-bit Windows 10 licenses to OEMs: https://tech.slashdot.org/story/20/05/14/148254/microsoft-takes-step-toward-phasing-out-32-bit-pc-support-for-windows-10 I want to feel sorry for you, dear 32-bit user. I really want to. But if you're masochist enough to run Win10 on 32-bit hardware, chances are you're already having a truly miserable experience on such a setup. And if that's your case, MS is already doing you a favor by not letting you do so anymore on your next new prebuilt PC. As much as I love to run new stuff on old hardware, this is Windows. You've been able to buy 64-bit x86-based personal computers for at least the last 15 years! If your internal Line-of-Business multimillion$$ crapplications won't work under Win64, it's time to lock them down inside virtual machines. Sure, it will be hard to convince Upper Management and the beancounters that spending money to let go the 16-bit legacy for good, but they will thank you next time they can't get 486s off eBay at sane prices, or when you get hit by ransomware due to outdated software. Next time I enter a bank or a supermarket, I do not want to see your fancy new i5 Thinkcentres or Optiplexes running bare metal Win32 (WOW64 is fine), thanks. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 20-05-15, 15:52 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #697 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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 in Resurrecting Visual Basic 3 shareware in VB6 (revision 1)
|
Dinosaur
Post: #698 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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™ |
tomman |
Posted on 20-05-16, 13:39 in I still HATE smartdevices
|
Dinosaur
Post: #699 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
Windows 10: because asking for consistency and control are now considered war crimes. ...just like cellphones! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
tomman |
Posted on 20-05-16, 15:46 in Resurrecting Visual Basic 3 shareware in VB6
|
Dinosaur
Post: #700 of 1318 Since: 10-30-18 Last post: 17 days Last view: 1 day |
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™ |