Drugwash

Hm, commandline parameters... So DOS-like. We're in Windows now. I'll try to add an 'ignore driver version' option. I'll probably ignore videocard version completely too, since one may even attempt to patch a 9x file on a 2000+ system with a non-nVidia card anyway.

Your code above matches 100% the one generated by the patcher. I've applied the patch to other (lower) versions as well but still have no way to test them. So far I have: 45.32 (my current 98SE driver, can't use a higher one as it disables AGP texture), 53.04, 56.64, 61.76, 66.94, 71.84, 77.72, 81.85, 81.98, 82.16, 82.69. @ dencorso: Should I lower the driver version minimum to 77.00 or is there any even lower version that may need patching? I'm too lazy to read all those topics you linked to.

No worries, I know you're very busy. The translator can be found at my CloudMe repository in my signature below. The SIBT folder. Hope it helps.

Those missing NDIS APIs indicate a newer NDIS version which may very well be unusable under Win9x. Guess we hit a dead end here, unless Dell driver mentioned by farfigs11 above could somehow be patched. That is assuming there are no other hidden (run-time) dependencies.

Do you want me to update the translation application or does it still work correctly for the newest SiB++ version? I can't test any SiB version since I have nothing higher than XP around me.

OK, so I guess I should settle for a minimum driver version of 80.00 and card version 6000 (round figures). Well, probably not tomorrow since it's my birthday, but sometime next week I'll add those checks. Thanks!

Yes, that was to be expected. The code doesn't appear to work as it should (at least on your machine), but additionally there was that calculation bug that jumped to a wrong location leading to the protection error. The 'red fix' was only for that issue, for the rest is up to Mr. Loew. However, I've been working on an automated patcher based on the code pattern presented in first post and so far it appears to work correctly, but we'll have to wait for some additional fixes. While I'm here, does anybody know for sure which driver version is the very first to exhibit the shutdown bug so I could set the lower limit for the patcher? Also, which is the lowest card version that exhibits the bug in conjunction with the drivers? I'd like to set some kind of frame so as not to unnecessarily patch driver versions other than the ones that do need patching. Of course, all that if Mr. Loew agrees to the patcher - after all, it's not my code.

@ schwups: There may be a calculation error in the relative jump for 82.16 (if my logic is correct ). Please try to replace the values in red below: 31FCAC: 3C 32 75 02 B0 52 89 44 24 04 E9 45 4E E5 FF to 31FCAC: 3C 32 75 02 B0 52 89 44 24 04 E9 15 4F E5 FF For what it's worth I've used the XVI32 editor, simple and handy (click left pane, type hex values, click 'Save').

There are inconsistencies between http and https with their site. I have HTTPS Everywhere in Firefox which forces secure connections where possible and I see a https connection, but if initiated as https, a connection to CloudMe will fail. It has to be initiated as http. I've modified the link above accordingly, hopefully it'll work now. If not, try clearing file name from the link (final slash included). The whole driver package is almost 20MB. I can't even attempt to send it over e-mail earlier than the 20th of the month when my bandwidth gets restored to its full capacity. If nobody else provides you with the package until then, I will try either uploading to CloudMe (in case more people need it) or attaching to an e-mail to your Hotmail address.

Here it is nvcore.vxd 4.14.10.8216: link (hope it works, CloudMe had some issues lately)

Maybe the memory range needs to be tweaked in some inf, or maybe there's a hardware conflict (BIOS can't assign specific range) so another PCI slot should be tested (is it a PCI device?) Sorry for not being of much help, I have no Wi-Fi device whatsoever around the house.

Great news, thank you! I've patched the only machine I have that uses 82.69, over the network, live, without a hiccup. Nothing blew up on a reboot. Unfortunately I have no series 6/7 nVidia card to test the effectiveness of the patch but at least it doesn't bother the GeForce2 MX440.

I see. So on my 98SE machine the official build works because KernelEx takes care of TryEnterCriticalSection (I looked through the sources). Guess it's worth stating that KernelEx users on 98SE/ME can use official builds of SQLite provided the library is set to 98SE or ME compatibility, respectively. Non-KernelEx users should use these libraries fixed by blackwingcat. Arigatou gozaimash!ta! (somebody should seriously look through the board filters because NOT all words that CONTAIN sh!t are actually profanities )

Thank you! What exactly is the problem with official SQLite builds? With KernelEx installed and set to Windows 98SE compatibility, official builds work on my machine. Is there any set of tests available to thoroughly check the behavior of official+KernelEx builds versus your fixed builds?

Sorry for replying so late, been busy today. My 98SE system is nine years old and it has undergone a lot of replacements and additions during this time. I have KernelEx 4.5.2 and Kstub822 (which may not be of importance in this case) plus Auto-Patcher and Revolutions Pack. Most likely I already had DNSAPI.DLL installed prior to installing CloudMe, but my memory is fuzzy so I can't tell for certain - it's also possible I have "borrowed" it right then from somewhere. The version of DNSAPI.DLL installed on my system is 5.0.2181.1, said to be coming from Windows 2000 and it uses 'default' KernelEx settings. It also has five dependencies: msvcrt.dll, advapi32.dll, kernel32.dll, wsock32.dll, rpcrt4.dll. If possible, try to profile the CloudMe executable through Dependency Walker, see if there's any other missing files or APIs.

- Create a duplicate folder of C:\WINDOWS\KernelEx named, for example, KernelE0 (with all files inside) - Install newest version; old version will remain intact in the newly created folder above To switch between versions: - go to DOS or Safe Mode - rename the KernelEx folder to something else (such as KernelE1) - rename the KernelE0 folder to KernelEx - reboot normally On each switch just remember the name of the alternate folder will be either KernelE0 or KernelE1. To check which version you're running at any point in time, just run verify.exe from the current KernelEx folder.

Yes, that's the right place, thank you. It's a sticky post so I could've found it quite easily... if I remembered that. Theoretically there's also the problem whether the BIOS supports 48bit LBA or not. For completeness sake we can count in the possibility that the drive has been partitioned on another machine (48bit LBA-compatible) and then transferred to current machine. However, in this particular case an ICH7 board should support 48bit LBA since the chipset was first released in 2005.

Maybe the respective newer filter has unfulfilled dependencies. Please check with Dependency Walker or any other similar utility and see if there's any missing dependency file(s) and/or API(s). My version of JPEGIM32.FLT is 2003.1100.8165 and comes from MS Office 2003. I don't have any themes installed in the PLUS! folder so can't test, but placing a JPG image in C:\WINDOWS\WEB\Wallpaper does show it in the Display Properties > Background >Wallpaper list, so I guess the JPEG filter does work. However, as MrMateczko noted above, the service packs are usually only for English versions of the operating system - unless other specific language versions are available - and mixing different language files can lead to unwanted results. Anyway, thank you for the solution in regard to the filter issue. In short, for non-German speakers: extracting the original JPEGIM32.FLT filter from the Windows 98 CD and replacing the newer filter from the service pack with the extracted original one fixes the issue of missing JP(E)G-type wallpapers from the Display control panel when Desktop Themes are installed.

True, but only for people that know what they're doing and are willing to assume any possible inconvenience. There may always be someone who does not know the experimental nature of these builds and unknowingly break their system, so it's fair to issue such warning. Anyway, thank you for testing and I'm sorry it didn't work for you.

Wouldn't the patched HDD driver (ESDI_506.PDR) be required for disks larger than 128GB? The 98SE version can be found here: http://www.mdgx.com/add.htm#BHD Dunno if/where there is a Win95-compatible version. Maybe with a patched HDD driver at least Paragon's NTFS driver would work.

Please note the KernelEx builds at my repository are experimental and untested. Do not install them on working/critical machines. Unfortunately I've been too busy in real life and therefore unable to patch the sources to R9 and build. No idea about the IE error - I used to use SlimBrowser under 98SE but uninstalled it after it started erroring out and replaced it with Firefox 9.0.1.

You can find dosstub.exe in KernelEx4520155_src.7z at my repository - it's a 64 byte file. XP-SP3 (in my tests) does not recognize LOCALAPPDATA as an environment variable - is it only available/declared in newer OS versions? Off-topic, I'd like to know how to programmatically get that variable in NT/2000+ OS versions, for an unrelated script I'm building.

Thank you! Just to make it clear for myself and any others interested: this package is cumulative - meaning it contains all changes since official 4.5.2 - and has to be applied to the official 4.5.2 sources to get to the current 4.5.2015.9, right? I'll set up a separate branch with 4.5.2, apply the above package and check against my old setup, to see what else has to be done to get a full batch in one shot. When ready I'll try to pack up the changed files for further testing.

Hey, jumper, glad to see you back! Have you managed to set up your environment for a full batch compilation? If not, could you please try the R5 at my repository (being latest available at the time of posting) and see if it does the job and it's got no wrong settings or bugs? It would be good to sync our settings so that little to no project changes would be required for each subsequent revision. I currently have no helper tool installed on my 98SE system (such as diff, Tortoise SVN or the like) so I'm doing all the patching manually which is error prone. If you know of such tool that doesn't slow down the system (I remember Tortoise did slow it down badly because of its shell extensions, reason why I uninstalled it years ago), please refer me to it.

Unless you have a strong reason for sticking with Win95, I'd suggest trying Win98SE. It's more flexible, has powerful updates (official and unofficial) and may just fit the job. If you can find an original CD with valid key and the price is affordable then you may try this. Just out of curiosity: how much did the 95 CD cost, all in all and how much would a 98SE one cost, if available at the same store?