Drugwash

Capacitors could have been replaced if nothing else blew up to make the board unusable. I did that quite a few times for me and friends. But now it's too late. Well, enjoy your Lego. :)

There is this concept of working directory. In your case you launched the executable with a full path from a different directory than the one the executable lied in, and it worked for running the exe, but the working directory remained the one where you launched the command from. As the exe most likely works with relative paths it was looking for the source file NVCORE.BAK in the working directory, that is C:\ (or whatever the DOS path was in the command window), instead of C.\WINDOWS\SYSTEM, and obviously it couldn't find it there. :) Anyway, glad you finally figured it out. Good luck ahead!

Theoretically it shouldn't, in normal operation. AFAIK Windows doesn't care about the filename case as Linux does, but I'm not 100% sure how this works in DOS mode. It's been quite a while since last tinkering with DOS and 9x, and my memory is failing rapidly. Besides that there is an admittedly slight possibility that the comparison code in the patch would be very strict. Long gone are the days when I would quickly disassemble the code to see how it works, so can't say anything for sure. But an all-caps filename would easily chuck this off the list. Well, that's about it, can't think of anything else. Hope you get to the bottom of it one way or another. Viel Glück!

Something in Goodmaneuver's reply above made me think of a few details that may be of importance. Make sure that: - the NVCORE.BAK file (which should be the original NVCORE.VXD renamed by you) has no read-only and/or hidden attribute; if so remove attributes; - the filename case is exactly as required, i.e. not NVCORE.bak/nvcore.bak/nvcore.BAK or any other variations thereof; - the patcher executable PATCHNVC.EXE lies in the same folder as NVCORE.BAK ([C:\]WINDOWS\SYSTEM); - the command path (either in pure DOS mode or Safe mode DOS window) is set to [C:\]WINDOWS\SYSTEM; As I understand it the file NVCORE.BAK would be the source file while NVCORE.VXD would be the destination - that is, the final, patched file. If the patcher cannot open that file it could be either if it doesn't exist at the required location; has hidden attribute; it cannot be written to (read-only attribute); filename comparison is case-sensitive and doesn't match the requirement; code sequence(s) in the source file don't match what the patcher is expecting. Wish the error message would be more verbose. For the latter case - code mismatch - there is nothing to be done, unfortunately, as the patch author isn't around anymore to analyze the code and modify the patcher. Only chance would be for you to try a different version of the video driver, as I seem to recall there were at least a couple of them available years ago. But best would be to perform a binary comparison of the same NVCORE.VXD between the currently installed driver and any other package variants, to avoid the hassle of installation in case those files are binary identical.

Sorry I couldn't help more. Thank you for your condolences. Many healthy and happy years ahead to you and the family!

I'm still alive, at least; dunno how well that is but it certainly could've been worse. My mother just passed away last month, and I'm about to get entangled in legal papers regarding the enheritance of her flat. Thank you for asking. Hope you're doing well too. Theoretically anything is possible although if the archive were broken I suppose you would've received an error of some sort at unpack time. As for the patch code itself - well, the documentation does mention your video card being somewhat newer than others and using certain different methods or whatever, so again theoretically it's possible for the code not to be perfect, reason why the author mentioned he should be contacted in case of failure. Unfortunately that is no longer possible now - may he rest in peace. For what it's worth here's the checksums calculated now for the package I had here since five years ago: MD5: 751d90ff7c651ea2d56c9d38644adcd3 *PTCHNVSZ.zip SHA-1: 7d4b9940f59a51fdbb030225c6f53907b04d6017 *PTCHNVSZ.zip MD5: 75e52e901928486098222b482d25371b *CWSDPMI.EXE 006ae40ed6efe8b3a8bbc0b4f7812ac6 *NVCHECK.EXE 5bcd26079eb14f601bbb67051ddcda61 *NVFLASH.EXE 4923ec18e90cac112407bae512842b76 *NVSIZE.EXE 77a4a4bd08f7e8a9da85a351a69c8514 *PATCHNVC.EXE 0b1a3003498b9f1e9c3d1ba372a59ff0 *PATCHOPT.EXE 1f756cc0108f0455ecd112059e5820f6 *PTCHNVSZ.EXE a7d52d595a285a7c4f0f6eabdb0cdc1c *FIXEOI.VXD f3fb4a63171dca8e3ee42e26c3d27dd4 *TESTEOI.VXD SHA-1: c10c8d48bc201f2d62b59c2c23c59864777abcfb *CWSDPMI.EXE 321adf12b2c60dd67cc4cf7b3c702cac7aaea67f *NVCHECK.EXE bb7ecc13d68710cd183d06ddb40caa9e0b12e9db *NVFLASH.EXE 277ffbd8c887ff384ecfbc78f5579c7ea7a5b1d7 *NVSIZE.EXE 4f22262aa2319c6f5e14a8f62deb0ed8961e4f27 *PATCHNVC.EXE f539192da5da4d6e3072e066a9248af4acbec243 *PATCHOPT.EXE 027e319484f093d73174ccd176ea8426a1669c17 *PTCHNVSZ.EXE c274a9f2d59a0ed351ffc0d6c0e0e497f7b9878e *FIXEOI.VXD 0ad0ee47ab532c0081f5970e876f027faf95124b *TESTEOI.VXD Personally I don't believe the patch would contain a "time bomb" as it's called considering it originally was a one-time payment commercial software. But since it is easy to set back time - albeit risky with regard to other registered commercial applications that may get confused - I guess you could try that too as a last resort. Either way good luck!

Please make sure you followed the required steps precisely as mentioned in MANUAL.TXT, especially #8: Can't think of anything else, sorry.

The SAB home site is being actively blocked in a few countries apparently, besides it possibly being blocked internally. Two of the ISPs I'm subscribed to actively block most if not all RU domains currently. Recently I was able to reach rt.com (random choice) through Tor on one ISP but today startallback.com was unreachable even through Tor on the other ISP. Not Tihiy's fault obviously. It's all getting ridiculous but I'll refrain from further comments as free speech has long become an illusion.

Took me a year and then some to find this out. Maybe I shouldn't have. Would've thought everybody was here, as always, him included. Would've thought everything's just fine. But there it is... One of us - another one - has left for a while; just for a little Eternity and a day, and then who knows, maybe there will be a full board up there somewhere... Useless to repeat all the good things that have already been thought of, written, and/or spoken about Den. We all know how he was and what he did here. We will all miss him dearly. May he rest in peace! 🙏

You may get a few different replies here, each person may have their own favorite languages and tools. For me it has been AutoHotkey - derived years ago from AutoIt, mentioned above by @jaclaz. It's an interpreted, macro language, single-threaded so it has a few limitations in terms of speed, but it all depends on your goals. I've built my own tools years ago, and I still use a couple of them today under Linux Mint. So the language is pretty resilient at least for small scopes. If you decide to try it you should choose only version 1.0, which is the only one that can run on Win9x systems. It comes with its Help file - which is pretty well done but not exhaustive - and also its own compiler if you want to convert the scripts to executables. But on a machine with AHK installed correctly scripts can run as is, so one doesn't have to compile them everytime in order to test or run them. That's a plus when it comes to quick development. Incidentally I had already built a small tool that can compute hashes; it's geared towards media (video) files but file types are editable, it can basically compute hashes (MD5 and SHA1 only) for any file type. It's called StorageMediaCatalog and it can be found in the large package linked to in my signature below. Hope the Dropbox repository is still reachable. Good luck!

May happen for some reason. I managed to get the Translator script to correctly open the UTF-16BE files in both 32bit and 64bit mode and now it converts them to UTF-16LE automatically when saving. However nobody expressed their interest in the script so I postponed any further work on it. Guess it's much easier to translate by hand or through other tools.

@Tihiy Hi, long time no see. Things have changed quite a bit around here since I last visited the boards. Got a technical question for you since I thought I should update the Translator that has long fallen into oblivion: are the SAB uninstall paths/keys in registry the same as with SiB, or do they have their name and/or path changed? I'm asking this because the script needs to retrieve the full path to StartIsBackCfg.exe (or is that name also changed?) in order to provide the option of extracting translations from the executable itself in case download isn't possible and no other templates can be reached. Glad to see you alive and well.

Just earlier I downloaded a few recent translations in the idea of updating SiB Translator if necessary. While looking through those files I noticed the sl-si file uploaded by you, and the fr-FR file are both encoded as UTF-16BE, not UTF-16LE as the original one posted by Tihiy (and as requested by the comments inside the file). Not sure if that may be the reason for the mangled display in the resource editor/viewer but they may create problems for SiB itself and definitely do create problems in SiB Translator - the files won't load. Also nl-NL is encoded UTF-8 instead of UTF-16 but that one loads fine in Translator. Otherwise it appears the Translator does need to be updated, and a few things fixed or added. First of all the name: StartIsBack ==> StartAllBack. Then other minor issues I discovered just now when testing. Since my CloudMe account is long gone I guess nobody had a chance to try the Translator recently. Will update it and post a link for download. If anyone cares, that is.

Thank you for thinking of me. I already knew about that attempt as well as about Keysharp, AutohotkeyX and others. See this comment in AHK forums for details. In a world where options are slowly (or quickly) being taken away from us I think we should refrain from second-guessing other people's choices as at some point they may even become our own choices. Don't forget: allergies are treatable with close to 100% success. Be well!

I believe it's about WebComponents. A lot of sites are making use of that and as such older browsers became doomed. Even Pale Moon which is constantly being developed has difficulties implementing that. Strangely, the old version 9 of Midori does have at least partly implemented WebComponents, which allows log in and operations in WordPress blogs. For e-mail I am now using ClawsMail natively instead of POP Peeper which was used with Wine until about a month or so ago. That is in Linux. Win9x probably has much dimmer chances of getting something usable with respect to browsing and e-mail.