Drugwash

There was one report in main SiB++ topic that the translator crashes under Win10 x64 but works fine under Win7 x64. I can't test and debug under any 64bit system. If you Tihiy or anybody else can test the translator and provide some useful information I can try to fix it. Meanwhile I have uploaded v1.1.0.0 with updated internal comments matching the SiB++ template. There is also an experimental, completely untested x64 version. Feedback would be great but please be very careful, I have no idea what may happen.

Ah, good that you found a way to run the tool. I believe those missing strings can be found in the Russian translation file, which is the default template for translations. You can copy/paste the missing English strings from the Russian file to the German file and then use the translator to translate them. EDIT : Forgot how smart I was two years ago when releasing the tool. You can easily update a template without losing current translation: - In Input file > Source select 'Extract from config' - In next window mark checkboxes for 'de-DE' and 'ru-RU' - Click de-DE to have it selected - Mark 'Load higlighted item after extraction' - Click 'Extract' The English template strings to the left will be updated to the latest version while the translated ones will remain unchanged. Scroll to the bottom and you'll find the missing untranslated strings. And if that won't work for some reason, load the newly extracted de-DE, click 'Merge' and then load the newly extracted ru-RU. that should do the trick. /EDIT In the mean time I'm looking through the code to see what could be wrong. I'll try to compile it as a 64bit application. Thank you for your reports so far.

Oh, bummer! That's gonna be a problem since I have no x64 machine around to test and fix. Have you tried some compatibility mode, if available? Should work in 32bit XP compatibility. Or run it on another machine with an older 32bit system, if possible (and copy over the translation file to be edited). Sorry for the inconvenience! I'll try to revise the code but with no ability to test that will be like driving blindfolded.

Hallo, Paul! Please visit the translations topic here. I've built a translator application some time ago for StartIsBack, hopefully it still works for this version too. You may download it from my repository and run it, load the current German translation file and see if there are untranslated strings. Translate them yourself, save and see if it's working. Please save a backup copy of the original file before modifying it. You may submit the updated translation file to Tihiy for the next version. If you find any errors or glitches in the program itself, please report them to me. Viel glück!

You're welcome. I had already forgotten how to compile ASM but luckily remembered about the old WLL project so I looked through its files and found the batches. I never managed to work with a makefile for some reason, maybe VC6 interferes or I'm not as bright as I thought. Indeed, the switches come first and filename last, at least that's how I found them in my old batches. In my reply above I had just copy/pasted from shae's comment. It's possible that some compiler+linker combination accepts the other syntax too, though. Haven't tried that. Actually I'm not much into ASM lately, got my plate full of other things. Was just trying to help a bit. As for the rest of your project I'm not sure 98 will be happy being installed on drive D. I'm not even sure that will be possible. Anyway, if you first install 98 and then XP, the latter will ask to replace or preserve previous Windows version, so if you choose to preserve 98 you should get a boot menu to choose between 98 and XP. Well, at least in theory - haven't done multiboot in a very long time. There are topics about that around, I'm sure you'll find all the necessary info. For the 98 SATA driver you may either set the SATA interface in legacy mode in BIOS (which may slow down the drive operations) or purchase the SATA driver/patch (can't remember which is what) from Mr. Rudolph Loew (find him on these boards). I believe there are topics on that subject too. Good luck with your project!

Guess it's time to let it out in the open. After close consultations with Mr. Loew we managed to build a patcher that would automatically do the job without the need to hex edit the driver file. The patcher is flexible enough to allow a few variants of the code as it has been found through various tests and reports and it also allows private versions of the code for users with specific driver/hardware/OS combinations where none of the standard code versions apply. Such private code versions, however, would have to be manually written to the ini file of the patcher. The application will automatically create a backup copy of the original driver file in the same folder where the driver resides. Typically that would be the System folder for in-place patching. The user can also gather a few different driver versions in a single folder (renamed in a distinguishable manner) and patch the whole batch in one single operation. The application can also patch driver files even when it's launched under a different, NT-based system. However it has only been tested under XP-SP3 so far. In the unfortunate situation that a patch has gone bad - improper private code, corrupt ini file etc. - and the system would become unusable, the original file can be restored in DOS mode by renaming the backup file (typically nvcorebk.vxd) to nvcore.vxd. The patcher is a Win32 GUI application and cannot run in DOS mode - sorry for this limitation. Alternatively, multiboot systems can be rebooted to a different OS where the patcher could be launched, select the defective file's folder, mark the file in the list and choose 'Unpatch'. Driver files patched by this patcher can also be unpatched/restored even when the backup file is missing. In the most unfortunate situation when backup is missing and the file was patched manually or the file is somehow unpatchable, the application will ask you for the location of a manually saved backup to restore from. The log file created in application's folder will reflect the method used when unpatching. IMPORTANT : If you are going to use this application under a very secure system, please place it in a folder that has full read/write permissions, since it has to write to the ini file and create/append to the log file. The application has not been tested at all under Windows 95, 98 Gold (First Edition) or Millenium Edition. It is possible that certain API used by the application may not be implemented in Win95 or 98Gold. If you encounter any error messages or misfunction, please do report them as detailed as possible. The application is open-source, written in AutoHotkey and by default is compressed with UPX (my connection is most of the time capped at 15kB/s so I try to keep filesizes as low as possible). The sources are available in the same folder at the cloud repository. In the event the file is being flagged by your antivirus, please submit it to the VirusTotal site for analysis. Thank you very much Mr. Loew for the patch code itself, for testing, advices, reports and support! DOWNLOAD: v1.4.5.0 (direct linking to files is not allowed by CloudMe; also please have googleapis scripts allowed in your browser otherwise the page won't be available) Please note older versions are present in the download folder for historical purposes only. Do not use them - some will definitely corrupt the driver files and most use an older, incompatible version of the ini file and the patch code.

After reading the 'Problems & Limitations' page I'm gonna stick to Metapad.

Did you use the parameters mentioned by shae in post #2? TASM aefdisk /m9 /qTLINK aefdisk /xThese are mentioned in the original makefile and they could make a difference in code size. You may build a batch file in the same folder, add the above commands to it and launch it.

Recently I was riding "shotgun" with my ex-girlfriend somewhere out of city. And we got to another city where I happened to spend a couple years of my highschool. Many years went by. Her phone's GPS kept telling us to go right when the only way out was left and so on. Eventually I told her: "look around, use your common-sense and we'll find our way out". And so we did. GPS was trying to kill us both. People should stop trusting those tools because they may just end up in the wrong place, to say the least.

@shae: Those are exactly the same errors I got. Also TASM 4.1 but can't remember what package it comes from, I've installed it many years ago. Hopefully your changes are safe.

I've already read some time ago - can't remember where - reports from people that sniffed the Internet traffic from their Samsung TV and noticed that all the file names contained on a Flash stick connected to that TV unit were being transmitted to certain outside server(s). How about that for a privacy gone out the window?!? What should we do: use arbitrary numeric names for our files and keep a list of them all on devices that have no contact whatsoever with the Internet? Or just dump all the "smart" (way too smart and way too dangerous) devices and start living more sane and live lifes? I know I left my TV set broken a few years ago, pulled out the TV tuner from my computer, my phones still have keys and no internet capability and my refrigerator is about 30 years old and still working with a simple power outlet connection. But keep this in mind y'all: it's not the technology that's bad - it's the people and their (mis)use of it. Especially the people in a position that can take advantage of the capabilites and/or flaws of the technology for their own (obscure) interests which usually are against common people's interests.

Sounds too complicated for me at the moment, especially since I haven't done any ASM work in a handful of years. Moreover I don't quite trust the real site I found the package at. Maybe someday. Good luck!

Tried with TASM 4.1, won't work - same three errors. Got no other version to try with. Author should have mentioned which assembler/linker version(s) to use.

Sounds similar to the old PhoenixNet trick that raised the whole Internet community back then. Personally I'd rather swallow an angry porcupine than use an UEFI BIOS machine. On another note and slightly related to the AV company linked to in first post: how does it sound when, following an on-demand scan with both Sysclean and RootkitBuster which found nothing, one suddenly finds an apparently Dr.Watson-related executable installed in Common files\System folder and running, plus a hidden running CMD window that launched a hidden download and install of .NET 4.0 without asking user's consent and no notification whatsoever, besides silently enabling Windows Update (previously disabled by the user) which already tried to install a handful of updates (which were already present on the system)? I should be the most stupid person on Earth if I ever run an antivirus (especially from TrendMicro) on any of my systems unless it's built by me and I know what it's doing. :angrym:

AutoIt should come with its own compiler. Install the whole package and look in the program folder. However I don't know if the newer versions would work under 9x. I've never used AutoIt but only AutoHotkey which is derived from an older version of AutoIt but is different enough, especially now. AutoIt is being flagged by antivirus apps because many viruses have been built with it at some point in time. I myself found such beasts on friends' systems. And well, this is a free language and needs to be heavily bashed to favor garbage like .NET and others. No need to elaborate on this one. Anyway, I'm not sure the AutoIt commands themselves are buggy; since AFAIK the tool only launches what it thinks would be the appropriate unpacker for the current type of archive, it is possible that the bundled unpackers may be incompatible with 9x or they each need specific KernelEx compatibility set to operate properly. That's just an assumption though, as I quit trying to get Universal Extractor to work under 98SE quite a long time ago.

Sorry if I sounded that way, was just trying to explain how things are at the moment. Of course, anything's possible, including a common root cause. Finding it would be great. Please check your PMs.

We do not know the root cause yet. It may very well be different from 95 to 98 to ME. If we knew it, it would have been fixed already. Indeed the workaround does bypass a couple of system messages. Mr. Loew tested the patch - it's his code - and considers the bypass safe. The missing shutdown screen is just a minor inconvenience. A different version of the code may work for you, one that does not bypass that particular message, but you'll have to test that.

Unfortunately the solution for ME, if found, will be quite different from the current 98SE one. For this reason there can not be a single patched driver file that could be repacked. Each user will have to install (if not already installed) the original drivers - any version that works best for them - and then use the patcher which will detect the operating system and driver version and patch the file accordingly (and only if needed).

Because we can! Now seriously, the patch operation itself has been tested on a wide variety of driver versions just to make sure the logic of it stands firm. At some point we may receive requests for different language versions and the logic may work for them as well. Or not. Nobody needs to patch drivers that don't need patching. But it's good to have choices - it brings responsibility with it. Anyway, there is a version limit according to the feedback and that limit can be overridden if desired, for testing purposes or whatever. By the way, we still need testers for all flavors of Win95. And hopefully Mr. Loew will come up with a working version of the code for ME.

We're working on a generic patcher that can (at least theoretically) do the job for almost any driver version. It's almost done but it has only been tested on English language drivers, from 45.32 to 82.69. Should be ready for next week at the latest unless something interferes.

Well, technically you're right, we who realize the truth beyond the mascarade are probably the few. But I didn't want to take such position of superiority as I still consider myself - and by all means I am - a simple person.

Great talk! And true. But we, the many, do not own our own lives, do not own the product of our own minds. So how could we change the world for the better…?

Reminds me of the Michael Hastings case. Maybe Paul Walker too, althouth naysayers would immediately connect the 'Fast & Furious' movie franchise to the event saying he just asked for it. One of the reasons I would never own or drive a car and as much as possible avoid being a passenger in one.

Overwriting existing data may be risky. Maybe I should put the patcher on hold until problems get sorted out. Still, it could help for testing, instead of hex editing. Well, I'll just wait for a while.

Apparently this is getting complicated. We need extensive testing under Windows 95, 98, 98SE and ME in order to find the working code for each system and driver version combination. I will design the patcher with the ability to load specific patch code according to the current (or selected) OS version and driver file version. For that we need verified and working code for drivers starting with 77.72 to 82.69, each of them tested under Win 95, 98, 98SE and ME. Hopefully videocard series would not add any more complications to this. There is one more issue I just stumbled into: the available space for extra code may be extremely scarce for certain driver files. The 55.64 (even if that particular version is out of scope) couldn't hold the 15 bytes in the first code variant, not to mention the second one. If code grows much larger, we may have to find another address with enough empty space or simply abort the project, unless the files can be recompiled, which I very much doubt since the code is not publicly available.