Drugwash

Resource Hacker has become an ugly useless chunk of code. Old 9x-compatible versions can't deal with x64 binaries and other limitations while newer 9x-incompatible 4.x versions are buggy, ugly and completely unintuitive. I am trying to avoid it as much as possible. And then, the source code for Metapad is available. It's a sacrilege to hack the executable when you can elegantly fix the code. Speaking of fixes, I took on fully implementing UTF-8 but it's not going as smoothly as I thought/hoped. But I'm still pushing the rock uphill. I may look at registry <-> ini migration too at some point, as soon as I understand what's going on there and if those settings were left aside for a purpose or were just forgotten. There is one thing that makes everything harder: the two versions of Metapad. The LE edition uses a simple Edit control while the full edition uses RichEdit. Certain options/settings are not available from one edition to another so there may have been a common selection or just an overlook. I've seen your translation already, actually I downloaded them all as a paranoid collector that I am. Sadly my French is not as good as my English or my Italian (but I can still tell apart OK from Cancel, at least ). Unfortunately a Unicode RichEdit that could allow full Unicode is too hard for me to implement. Most likely all buffers would need doubled, text size should be measured in TCHARS and a lot of other changes I may not even be aware of. Since my knowledge of C/C++ is limited to what I gathered here and there as a self-taught hobbyist I'd rather not bite more than I could chew (which I may already have done ). I've chosen Metapad years ago for a single major reason: the Save button in the toolbar. Besides its lightweight, of course. And the 'Undo'/'Redo' options are also a big plus. Did Microsoft ever think to add such highly needed options in a straightforward manner to their lame Notepad? I bet they didn't, not even in Win10 - someone please slap me in the face if I'm wrong. Hence the logical choice. And no, Wordpad is not a choice for simple text files. Although admittedly it does employ a Unicode RichEdit (even v5.0) but only under NT-based systems (at least XP where I just checked).

Great, thanks, I didn't know that! Actually I'm mostly using the TotCmd 7-zip plug-in for packing/unpacking so didn't get a chance to become familiar with the official standalone 7-zip's features. I just hope I won't forget this (too soon). And now that I found the method I'll confirm both CRCs match the above so we can put this non-issue to rest.

Of course it's not crucial. But it is a good way to cross-check operations and their results if ever needed. Both my files match yours in size and date. Dunno how to get/calculate the CRC for this type of files. I'm pretty sure they'll match too, though.

TSM_RDME.TXT (5334 bytes dated 1996.02.21) in main installation folder says "Welcome to Borland Turbo Assembler and Tools 5.0". TSM_INST.TXT also has 5.0 all over it. Coincidence happens.

I was just replying to a metapad-related topic. Latest version is 3.6 and it still works fine in Win9x so I wonder why you wouldn't use that version in hope that any possible bugs that sent you to a wild goose chase have already been squashed. There's also the possiblity that in 98 you have word wrap enabled while in XP not, so depending on window size in 98 you may get different results. In my Metapad 3.6 under 98SE I see a total of 5526 lines in the statusbar. Personally I'm extremely reluctant to mess with my nine years old 98SE system by installing an older TASM. I have so many sistem files upgraded to WinME/2000/XP/+ versions that a badly built installer that doesn't take version number and modification date into account could very well screw up the entire system. I'm not taking that chance, no way. If the thing came in a humanly-usable archive type that could be manually unpacked and deployed, then maybe - just maybe - I would've given it a shot. But the way it looks - no. Anyway, when launching the batch file created as mentioned above, I see Turbo Assembler Version 4.1 with 3 warnings and 2 errors at lines 2743, 2919, 2921 and then Turbo Link Version 7.1.30.1 that can't open the object file (obviously due to preceding errors). The errors could be fixed according to shae's advices but I didn't go there. I also have a network printer recently purchased second-hand (Lexmark E352dn) and it works just fine in both 98SE and XP-SP3 with the appropriate drivers installed. There is at least a topic here where you can find very useful tips on installing network printers under 9x (I know it requires certain driver from HP to enable network printing under 9x and then a very good tip is to name the printer from its own settings something like LPT2…9). I've named it LPT4 (since LPT1-LPT3 were in use) and added its fixed IP (don't use dynamic IP with it, it may not work correctly) to the hosts files in both XP and 98SE. EDIT: @ shae: I've just performed the modifications you mentioned and compiled succesfully. The resulted file is bit-by-bit identical with yours. Apparently we are using the very same TASM installation. Unfortunately I don't have a testing system so functionality is still questionable.

I've never used a translation with Metapad. Although I have contributed a few translations for certain softwares back in the day, I realised that most of the times translations won't work. Certain languages have very long words and expressions that simply won't fit their corresponding controls (Statics, Buttons, Checkboxes, Radio buttons etc.) and abbreviations would only make things worse. Just for the sake of testing I loaded the italian translation in Metapad and on opening the Settings (Impostazioni) dialog there are about four cropped checkbox strings in first tab and about four or five cropped or abbreviated on fourth tab. My language also has many lengthy words and expressions so it'd be a waste of time translating unless I make the whole dialog larger, together with resizing the controls, then recompiling the application. I've also noticed the UTF-8 issue which doesn't convert the text at all in/out. And it really bugs me out that Unicode suport is not full, so for example if I drag Chinese/Japanese/Russian/etc. text to/from Metapad I'll only get question marks. That's due to the issue I mentioned somewhere above, that is the application is creating an ANSI RichEdit control, not a Unicode one which does work fine even under Win9x (see MyDiary at my repository and check control type using PIG - also one of my tools: metapad uses RichEdit20A while I'm using RichEdit20W or RICHEDIT50W if available through msftedit.dll). However, modifying the whole Metapad code to work with Unicode RichEdit is a bit beyond my C knowledge. I also find using a library for a translation to be an overkill (just like eMule used to have back when I maintained its translation) - a simple text file would do just fine (see SlimBrowser which I also used to translate a long time ago before it went all Unicode).

The other package contains the source code. Only useful to developers or people who do not trust the precompiled executable. Also required by the license. The application can patch any driver version provided there's enough space for the code so yes, it should work for 82.69 too. Currently only 98SE and ME have been tested and found working but if positive reports surface for other OS versions they will be mentioned in the documentation. Testers are welcome. Please do read all the available documentation, just to be on the safe side should anything unwanted occur.

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).