Drugwash

K.

Thank you! Is that... Visual Basic? It's gonna take me a while, now I'm fighting with wine. No, not WINE - real wine. (I know it's irrelevant, but we're only human after all...)

@Jumper: May I have the sources for this GCC patcher , please? I'd like to try an AHK approach with auto-backup option. Oh and they don't stop; on June 27 they released version 1.8.3. Just downloaded it, haven't yet tried to UPX or patch it. Later edit: I've succesfully UPX-ed v 1.8.3 and it appears to work. At least it does connect/disconnect, since I got no files to sync at this moment. Haven't tried gccfix.

Such topic could easily extend inedefinitely. I see people always asking for compatibility with newer applications and can't stop wondering how many of the older, native-9x ones, are still being used. People always want 'the newest', 'the latest' just to follow the trend, not because they really need that. Of course, there are those 'new standards' that keep being 'upgraded' from time to time for the sole reason of offering leverage to commercial programmers to build and sell new versions of their applications. That's an ever turning wheel, driven by the current economy model at global scale. Then, software is more and more tied to hardware, which gets upgraded for the very same reason as above. Hardware upgrade requires software upgrade, then software upgrade requires hardware upgrade and so on and so forth, while choice has been taken from us constantly until it all became "my way or the highway". At some point we did stop. We had to stop, we can't pursue this madness as much as we'd try. This is a neverending game of greed and power. As I said, we could talk on this topic indefinitely, but this is not the right place and we wouldn't get to an unanymous conclusion anyway. Therefore I stop here, apologyzing for the off-topic. (fixed small grammar issue)

Using the sources to update KernelEx would be a better idea. But a question arises: when will we stop transforming 9x into NT?

Here's all the boot options for the BIOS revision R1.12 (3u112.zip) - unless the user specifically needs USB-CDROM or USB-HDD boot options enabled, the official BIOS image may be flashed in without any modification and all selectable options should be available. Personally I've flashed some BIOS images from HDD, by letting Win9x boot in DOS mode (F8 during boot -> Command prompt only) and running the flasher from a previously prepared folder in C:, to avoid any floppy issues - your mileage may vary.

The BIOS images are available from the official FTP here. Included there is a flashing utility. As far as I can tell, the latest available (3u112) has a few USB-related boot options, but two of them are disabled, namely USB-CDROM and USB-HDD. You may use ModBin 6 and maybe even a version of CBROM (haven't tried any yet) to enable those options.

There is a setting that turns a removable device into a fixed HDD device. Certain utilities can do that, however they cannot revert the setting to original - that can only be accomplished by rewriting the firmware. I did that some time ago, but meanwhile I lost the mobo that powered the SATA HDDs where all those utilities resided and I have no other SATA board in house. Try Flashboot.ru , I got many of the firmware tools from there. But please be careful how you use them or you may damage the USB stick! Also, some Phison tools tend to install some drivers or filters (forgot what exactly) which may disturb other USB devices' functionality. Better use them only on a testing/virtual machine.

Are there so many inf files in the 'other' folder? My system only has four of them: a bluetooth device, a printer, a webcam and a monitor. The infs only tell the system which driver file(s) to use (although some of them could be malformed and create troubles) but I'm afraid you'll have to work it out by trial and error. Just move or rename all of them, remove the associated devices from Device Manager and then on each reboot add/rename back one file, reboot again, let the system redetect the device and see which one breaks the system. It may be the inf or it may be the actual vxd/sys driver causing the problem.

Yep, and so it should. There are more such "migrated" APIs and they could be found by performing a cross-comparison between msimg32.dll's API and the Gdi**** API in NT-based systems' gdi32.dll. Adding them to Kext in advance shouldn't hurt. One thing to keep in mind is that according to MSDN there's a memory leak in msimg32's TransparentBlt (which I'm using in RPTE so it'd be nice to have this confirmed), so binding GdiTransparentBlt to TransparentBlt in Kext may impact on GDI resources.

GdiAlphaBlend is just the Gdi implementation (for consistency?) of AlphaBlend which already exists in msimg32.dll for Win9x. If possible, redirect the call to msimg32 in Kext and transparency effects should work (unless they're bound to something else that's not working).

Eh, I said it was a long time ago. But still, I remember for some apps (read 'games') I had to add some DOS drivers and/or remove others and there just may be something else besides those two. Maybe some entries in wininit.ini...? Dunno, I feel it was more than autoexec and config. But maybe I'm wrong. Wouldn't hurt to check though. I saw the OP has Norton (or Volkov?) Commander so it shouldn't be hard to navigate the Windows folder and look at some important files (and search for possible backups of those). Hopefully the problem will be solved without reinstalling.

Guys, hold on for a second! From what I've read, it looks very similar to a situation I've encountered often many years ago. Some DOS games wouldn't run properly in Windows mode so they would require certain properties modified in their .pif shortcut which made the system reboot in DOS mode and load that game. Upon exiting the game normally, the system would reboot to Windows mode. Now, if for some reason the user would break the chain and exit the game forcibly, the system wouldn't boot to Windows anymore. Why? Because some system file remained permanently changed for a DOS configuration. I suspect it's system.ini which has been swapped for system.cb or some other private copy. In that case, there should be a backup of the original system.ini which - when restored (that is, renamed to system.ini) - would then regain ability to boot to Windows mode. Of course, the command in autoexec.bat that launches the application should be REM-ed as well. EDIT: There may be changes in config.sys too; look for a backup copy of the original, as well as a backup copy of autoexec.bat and system.ini. If it's not system.ini then it must be some other similar file in the WINDOWS folder. My memory is long gone, it's been too many years since last experienced this. But you get the idea. No need to reinstall or botch the system in any way. Good luck!

My guess is that CPUID may be used to get actual, real information about the current CPU - especially the cache part - which would then be formatted and pasted in the SYSTEM_LOGICAL_PROCESSOR_INFORMATION stucture that GetLogicalProcessorInformation() should return. Although most applications may only want to know how many CPU cores/threads are available, some of them may also need the cache details or the NumaNode relationship (where available). To be on the safe side, I think cache information should be accurate and not just filled with some "standard" figures. Simply returning FALSE from a stub may hint the application that it's running on an unsupported system, which may subsequently drive it to just bail out. So it'll be that certain applications would work, others would exit, which doesn't make it the perfect solution. EDIT: Here's some useful information regarding this API and the structure it's using: NumaExplorer At the same site there's detailed information on CPUID and its usage: CPUID Explorer (2 pages)

That may be both a check for minimum supported OS and information necessary for better distribution of tasks in case of hyperthreading/multicore processors. MSDN states minimum supported OS for that API is Server 2003/XP x64/Vista ... however it exists in XP-SP3 x86 too (tested by myself just earlier)[1]. I'm afraid you're stretching way too far. Even if that API could somehow be implemented (I doubt it can be stubbed since it has to fill a buffer with information that may be used by the application), there may always be other APIs required. Dunno what that game is - I'm not into gaming - but judging by the name it's too recent and requirements may just be too high. If anybody else knows better please speak up. [1] (edit: some correction was needed, because as always Microsoft's documentation is incomplete, misleading and therefore mostly useless)

Apparently, d3dx9_43.dll (the x86 version) has only one missing dependency in kernel32.dll, which is GetFileSizeEx. AFAIK, this one is already implemented in KernelEx, so choosing Win2000 or XP-SP2 compatibility for the file might allow it to work. But one never knows for sure until they actually try it. The respective file can be found in the June 2010 version of the DirectX package (and probably other newer versions, if any).

Ouch! Is it me or Windows 7 looks too much similar to Linux, as in bulky and screen space wasting? Nevermind... Looks like I'll have to perform some more tests in 7. Latests versions were not tested there at all. The keyboard/mouse hook is normal when trying to run the Unicode version under 9x. AHK thinks it's safe to install those hooks, which normally happens only when it detects an NT-based OS (which KernelEx compatibility fools it into believing). So no worries there (and there's nothing I can do about it anyway). The naming error is due to a limitation in variable names. Some characters are not allowed, while they can be present in file names. Since I based the data storage on skin.ini and folder names, such bug was inherent. I just hoped it wouldn't happen, but when did my hopes ever come true... I'll try to change the storage system to work around this limitation. Just FYI, the issue is with the dash in the theme name "Homestead-ORIG" - if you replace it with underscore as in "Homestead_ORIG" it'll be OK. Spaces are not allowed either, so I'll have to find a better way. Thank you very much for testing and reporting! Later edit: Looking closer at the Win7 screenshot, a couple of questions come to mind: - does that machine use a nonstandard DPI setting? - is it a x64 machine/OS? I'm asking this because the Unicode AHK version I'm using to build the Unicode RPTE claims to be DPI-aware but I've never been testing those builds on a nonstandard DPI machine so I'm not sure how it looks and behaves under such circumstances. As for running under x64, some of the structures used in my wrappers are not yet x64-compatible, partly because of lack of proper information and partly because I have no x64 machine to test on. So failure of some sort is to be expected. Regardless, I see there are other problems under Win7 x86 in the Preview tab and there's also the known issue of Rebar not automatically resizing/moving when main window is being resized. Fixing those might take a while. I'll soon be uploading a bugfix version that takes care of the theme naming issue.

New version 1.0.0.12 of the theme editor is up (see the RPTE folder in my signature). Didn't test it under Win7, may have glitches and bugs. Please test and report bugs (except for flickering in preview - that's known).

Just a heads up: CloudMe 1.8.1 has been released on May 12 and still works with the UPX method. Not sure if I mentioned it already in the other thread, but I already have VC9 and VC10 runtimes (patched) in the System folder, so I moved those that came with CloudMe out of its folder. The VC11 runtimes should stay. This may be important if the unpatched runtimes won't work even after UPX-ing. I also wrote a small AHK script that automates the UPX packing of the files, if anyone cares. It saves a log and attempts to set KernelEx compatibility for unloadable libraries (this may not work). With a few small changes it could be made to pack files in any folder. The upx.exe must be in the same folder with the script and it's highly recommended to run it from a short path, such as C:\upx, C:\Temp or similar. AHK Basic (ANSI) can hopefully be found here.

Good luck finding the patch! Any limitation in 9x is worth overcome. Just please bear in mind possible differences between files of other language than English, if possible, so the patch could work universally.

Now that you mentioned it, I tried that in XP and the ActiveX/OCX tab does indeed appear but the LoadTypeLib error message is still there. Of course, it may be also a bug/limitation in that plug-in. Didn't pursue this matter further since I'm not realy interested.

Shooting in the dark: is it possible some system file(s) fail to get restored (if backed up, that is) at some point during the installation? Thinking of SYSTEM.INI, WIN.INI. Alternatively, wrong settings may be written to such file. I'm thinking of Tihiy's Safe-Mode patch that installs a few system files and modifies SYSTEM.CB. Could you check the values in SYSTEM.INI for: [boot]386grabber=?display.drv=?[386enh]display=?If you see vgadib.3gr, svga256.drv, vddsvga.386 in there, it's the Safe Mode fix acting up. Otherwise dunno what to say.

New version 1.0.0.10 of the editor is up (open link in my signature below, see the RPTE folder). Finally, first attempt at checking bitmap height against taskbar height. Apparently there's a margin of 7px that can be reached without triggering the size bug. I've hardcoded that value and all checks are performed against it added to taskbar height from Global section. In case of mismatch, the details area will display some information. It would be helpful if this could be tested on other machines with different Common Controls versions, to make sure the value of 7 is consistent.

I stand corrected. Sometimes the short name may not help in this situation. I've just tested by creating a folder called test•2 (note the bullet character) and it appears as TEST2 in DOS, however it cannot be deleted - neither from Windows (directly or DOS prompt) nor from true DOS. Funny thing is I proceeded creating a second folder with the very same name and it got created, exactly as before, so now there's two identically named folders in the same location, both of them with the same Long File name and same DOS short name and both undeletable! Oh man, I've been asking for trouble! Now, on to fixing it. Back to Windows, ran a Scandisk on that drive. Found errors, fixed them automatically. In the respective folder, one of the test names got changed to TEST-2 in both Long File Name and DOS short name. I could delete that one right away. The other one was changed to TEST[]2 (actually there's an unprintable character in there) in LFN while short name is still TEST2. But still can't be opened or deleted. Ran Scandisk once more on that drive, after deleting first fixed folder. Again found errors, again fixed them. But last folder's name wasn't changed this time and is still undeletable. Opened a file manager on a XP machine and looked at that folder over the network. Long name appears as TEST•2, so XP recognizes the bullet character correctly while 98SE shows it as a blank nonprintable character. But not even XP can delete it over the network (no problems with permissions). Last chance: back to true DOS, ran a DOS scandisk. Stumbled into that folder, told me it's invalid (funninest thing is, the name looked correct in true DOS!), blah-blah. Offered to fix it, accepted: 1 invalid directory entry was removed 1 lost cluster was saved as a file Back to Windows, the offending folder is no more (obviously). The saved cluster is empty, as the folder had nothing in it. I'm not sure what would have happened if there were files/subfolders in there, but I really don't wanna test that scenario as I already wasted a lot of time with this. Bottom line is, when Windows fails, true DOS comes to rescue. One way or another, problem gets solved. Now back to more important stuff.

I don't think the short name can be corrupted so easily (if at all). The FAT structure is somewhat strange but it has its well-defined structure. Incidentally I stumbled into this recently when following a hardware crash I found myself with 945 stray files that chkdsk (on XP) converted to .chk. In my desperate attempts to restore the files (I'm building a rescue utility for this) I had to deal with FAT file name structure. The long file name has a CRC that has to match the short name and if that fails there's no tell what Scandisk/Chkdisk may do to those files. P.S. You mean this one?