Drugwash

We don't know what their stance is regarding Win9x. Maybe, just maybe, they would at least check the code to see if the bug(s) would affect NT-based systems as well. I'd give them some time, maybe they'll receive feedback from other sources.

There's a slim chance that this actually is a bug (or a sum of bugs) and not intended behavior, especially since it manifests itself randomly. Guys at FastStone have been kind enough so far as to keep compatibility so I sincerely hope the issue will be fixed.

Such issues are hard to spot, don't worry. Dunno how the Unicode names and paths are handled internally but it's possible that in certain situations a Unicode name/path may be passed to/from an API that can't handle it (correctly) under 9x, regardless of any KernelEx compatibility mode. Maybe disabling KernelEx extensions for the main executable could help - haven't tried that, too much overhead now so I just reverted to previous 5.3 version.

Hm, strange. When I first tried, after resizing an image, there was no save dialog. After relaunching the application, it works. Maybe there still are quirks somewhere.

Well, now we can officially say FastStone Image Viewer ended its 9x compatibility. The 'Save as' function is dead.

I can create/check SFV and MD5 from within Total Commander but not other checksum types. Never needed any, actually. This time I was just curious. I could actually create/read/compare/update an executable/library's built-in CRC, it's partly implemented in one of my tools (DllDetails). But this is a different thing.

Completely unrelated to Outlook but then again I never used it and never will: have you tried POP Peeper as an e-mail application? Used to work with the help of KernelEx, at least the last 4.0 beta did - dunno about 4.1, I only tested it in XP. Got one AOL account and three Yahoo! accounts. GMail used to work too but I'm keeping that one out for some reason. However it is a memory hog, using SQLite3 databases for each account. Actively maintained. No need to buy the Pro version unless you need private/Spam folders checked. SSL libraries available on their site. Dunno, may be worth a try if Outlook won't budge. Just sayin'.

Dunno, might not happen in this life, so don't hold your breath.

When I say Win95 I mean people that have access to different Win95 flavors and want to try 8x.xx drivers and series 6/7 NVIDIA cards may need this patch and we're waiting for reports whether there is a need for the patch and which OS version/driver/card/patch combination they work on. So far there's only LoneCrusader's feedback below, using Win95C and driver 81.98. However I got feedback that the patcher doesn't work correctly under Win95. I'm guessing a few APIs may be missing so now I'm going through the code trying to find alternatives that should work under Win95 too. Therefore testing the patcher under Win95 should be put on hold for a little while until I come up with a proper version. However, manually testing different versions of the code under Win95 would be very useful. Thank you for testing the code under Win95, now we have at least one marker as to what code should be used for those systems. The code you found will be added to the ini for the next version of the patcher.

That is why there are choices: one doesn't work - try the next. WinME has only two code versions anyway so either 'Wide' or 'Full' (which are identical) should do the job if 'Safe' doesn't. Now there's a new version: v1.4.6.0 - Added automatic ability to overpatch a file already patched by this patcher (NOT THOROUGHLY TESTED!) - Added automatic choice of last selected OS version (only when run under NT-based systems) - Fixed random empty code type selection (reported by schwups) - GUI improvements to eliminate confusion about utility of 'code type' selector - Minor code improvements Basically this version makes it even easier: try 'Safe' patch; if it doesn't work, choose 'Wide' and patch over, without the need to unpatch first. If it still doesn't work, choose 'Full', patch again and if that still won't work then it's time for Mr. Loew to find a fourth message to bypass. Well, hopefully that won't be the case. No Win95 or 98Gold testers yet? I'm so sad… Anyway, enjoy! Beats me. Mr. Loew, you got the floor.

I'll look into that, trying to reproduce. Maybe your sistem is too fast (or too slow?). Al I got here is a 667MHz PIII (my main 98SE machine) and a 1.8GHz P4 (XP). The other 98SE testing machine is similar to the P4 one. No WinME unfortunately. But will see what can be done. Thanks again.

This should not happen. There is an entry in the ini file for this selection and there is also a failsafe in the code in case that ini entry is missing. Have you changed any values in the ini file before running the patcher for the first time? Can you confirm there is the entry CodeType=1 in the Preferences section of the original ini? Did you launch the patcher first time with the original ini present in its folder? The only way this could happen would be for the ini entry to contain a value out of range (1-4). Unless ME is somehow behaving strangely when reading from ini, but I doubt that.

Hm, did you get an empty selection for 'code type'? It should be preselected to 'Safe' on first run and then saved/restored through the ini file. I've set the default to 'Safe' because there are systems that work with only one message bypassed, as found by Mr. Loew and reported through the topic. Logic is not to overdo when simple version works. For systems that don't work with the single message approach there are the other options in 'code type'. The user would have to test each option one at a time and stick with the one that works for that particular system. That is precisely why there is a 'Private' option, where the user can try their own particular code version which doesn't fit any of the standard ones. As for the byte changes you noticed, they are necessary for a failsafe unpatch/restore in case the backup file is damaged or missing. The first difference at 0x144 is segment length, increased by one. The second difference is additional code length, appended to the actual running code (and reason why segment length was increased). That value is essential for a succesful restore in the above-mentioned situation and also for an upcoming overpatch ability (repatch without having to unpatch first). I'm glad it all works for you without problems. Thanks again.

Yes, code type option is common to both in-place and batch file selection. Sorry for not having made it more intuitive - I'll revise the GUI in that regard. Thank you for giving me good ideas.

Thank you for testing and feedback. I assume you used the 'Safe' code type option which is the default. That one may not work on every system. Please unpatch the file and then repatch selecting 'Wide' or 'Full' (which are both the same, currently, for WinME). There is no need to reboot or reload the program between operations. Just now I realised a repatch operation was never considered. When I get to build a newer version I'll make it repatch without the need to unpatch first, but it will only work for files patched with the patcher, not those manually patched.

And which Unicode font is it going to choose? It would need to parse all installed fonts to select one that has got a corresponding unicode plane. AFAIK (I might be wrong) no text editor does this regardless of OS. The closest to this is probably Babelpad adequately configured in composite font mode. I would not know anything about the rest as i don't use IME but I suspect that if you select the right codepage (or some UTF flavor) in Akelpad it might work OK. Many applications lose userbase because of badly chosen defaults and unintuitive behavior. One can choose a default codepage, a codepage for new file but it's of no use - still garbled text. Moreover, once there's English text and Japanese text in the same window/document it appears very clear that document should be treated as Unicode. Still, input from keyboard layout other than system default will appear in the default ANSI encoding, regardless even of the chosen font's codepage. I have Babelpad 1.9.3 built in 2005 but couldn't get it to do the job. I'll let this rest for now.

Indeed it can, my bad. Forgot to select the font first. However, I believe a smart editor can select a Unicode font at least when Unicode text is pasted from clipboard or dragged over. At the very least it could ask the user if they want the text as ANSI (current code page) or Unicode, because clipboard always contains both versions and there are APIs to check clipboard contents. Oh and another thing I just checked (hopefully I'm not wrong again): OS version is English, regional settings are Romanian, I switched keyboard layout to Russian (Japanese IME is not enabled in Akelpad) and the text comes out garbled - the editor doesn't take into account that we are on an ANSI OS with a keyboard layout that doesn't match either OS language or regional language, which should've triggered at least an ANSI codepage conversion if not direct Unicode input. I mean, I can type both Russian and Japanese in an Office document under 98SE - why would it be so hard for other editors to do that? Oh, because nobody cares about 9x anymore, right…

Let me put it this way: is there any simple text editor out there that can take a copy/paste from a Unicode-aware application (JWPce, for example) and display the Unicode text correctly under 9x? Because Notepad can't, Metapad can't, Akelpad can't… Notepad2-mod can, actually, but only with certain font (for me it worked with Arial Unicode MS) and it has serious text selection/alignment problems. Weirdly, similarly to Notepad+ (IIRC) it uses a ListView control instead of a RichEdit control. Unfortunately, due to the alignment issues (and possibly others) it can't be used in programming. I think I'm gonna end up writing my own editor, someday…

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.