Drugwash

Another undocumented offset? The patcher is not meant as an in-depth analyser but the code that reads the VI from LE files can be ported over and enhanced. But first things first.

You forgot about Shutdown Patcher which can read VersionInfo from VXDs equally well. Ahem, almost equally well because I did stumble into that duplicate label issue and left it as is (since none of the nvcore drivers suffer from it). But with a little help from my friends I could fix it and maybe port the code to a standalone GUI application. B)

Thank your for continued testing and feedback! Problem with empty selection is yet a mystery - either a bug in the AHK interpretor or a misunderstanding of the behavior on my part. Thing is, if the corresponding entry in the ini is blank, the default value that should be automatically substituted by the script doesn't kick in. So I have to double-check if the entry is empty and force a default value again. Plus the usage of a variable that was reinitialized after being set. No big deal but still disturbing as I know it used to work. Version 1.5.1.0 was not announced due to a few display issues under Win95 which I'm trying to solve at the moment. Everything should work fine under 98 and later though. Sorry for the ME bug, it was a tiny but critical overlook when copy/pasting code between sections. Glad it works for you now. A new version will be announced as soon as I sort these 95-related problems out.

Tihiy, maybe to make everyone happy you could add a suboption to the update notifier, something like: [_] Also notify of beta/RC/minor updates It will then be people's choice whether to follow and install such versions, reagrdless of whether they already are on beta/minor channel or not.

They must've adjusted the compatibility list sometime these days - I'm 99% positive I saw 98/ME up there when downloading 5.4 following your announcement above. In that case there's nothing we can do. Another one bites the dust…

Glad you got things sorted out. And of course, to each their own so if this application pleases you then everything's fine. BTW, I created a VC6 language project from the VS2013 one using prjconverter but for building a working language library the respective translated .rc file is required. It may still need some tweaking (output is 164kB compared to original 151kB). If anyone wants the .dsp/.dsw files just wave your hand or whistle.

Since many years ago I have something against that application. Can't say what it is - maybe the ugly icon, maybe something else. I've installed it now though, to test in regard to your problem. First thing that caught my eye was a default plug-in, the first one listed in the plug-ins window: ANSI2UNICODE.DLL. That one may have to be checked/uninstalled when testing under 9x. Second thing was the checkbox saying "Load Unicode PlugIn at program start [...]" when opening the Language item in Properties (Main Menu > Options > Change language). Now, apparently the main app can't load the respective German language file even in Default compatibility mode, regardless of the state of the aforementioned checkbox. Disabling kernel extensions had an immediate negative effect on the toolbar icons, corrupting them. German language library still can't be loaded. Changind compatibility mode to Windows 98SE allowed the German language to load, but the icons were much more corrupted than before. First half of them illegible - luckily there are tooltips. In Windows2000 compatibility language file is loaded and toolbar icons appear correctly. Functionality untested. Loading Romanian translation with KernelEx extensions disabled was succesful, but icons are still corrupted. Language file is old 4.37 version. Changing KernelEx to Default compatibility mode fixed the icons issue and language is still loaded. I would conclude that the language SDK for the current version may need some tweaking or at least a VC6-compatible project be derived from the current VS2013 project and language files be compiled under Win9x and VC6 for full ANSI compatibility. But that has to be done on the user side. P.S. I still hate IrfanView and I still don't know why... (I can't live without typos…)

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…