loblo

As already mentioned in my initial post: PotPlayer 1.6.46541 which is the current/latest version. Way better than VLC in every way IMO. Supports HEVC & VP9 decoding. LavFilters 0.59.1 nightly build of 2013-12-16 at http://roy.orz.hm/lavf-w32-nightlies/lavf-my131216-210f2d6.7z. All subsequent builds also crash in kexbases.dll. Supports HEVC & VP9 decoding. Any Gimp version that has exe/dll crashing up to the current/latest 2.8.10. Those are the only ones I know for sure but there are certainly many more for you to discover.

I was bored so I found a download for it on softpedia and yes it's entirely possible to run it. Requires Kernelex and KexStubs though and the files must be copied from the appdata folder before exiting the installer. Sound is choppy for some reason but other than that it runs fine and it's so stupid it's actually funny...

Interesting, I have set the .text section of all the VLC 2.1.3 files to be writable and it works as good as UPXing apparently. It's very easy to do with NW PE Builder in case anyone's interested in using this method, no batch processing possible unlike with the UPX method however. The files that don't have a problem don't have a writable .text section so it's still very mysterious to me what is going on but it sure is nice to have an alternate solution. Jumper, if you've got some spare time, could you look into the recent built of executables that crash in kexbases.dll? It seems like a generic issue and it's very annoying. As per faultlog.txt most crash in kexbases.dll at 0177:bfa41cbe and have no apparent missing functions/dependencies in common which seem to exclude a problem with KernelEx inadequate definitions. I can run the affected console programs without crashing in kexbases by profiling them in Dependency Walker, GUI apps fail to start in DW for other (and quite usual for KernelEx only apps) reasons. Presumably interesting examples: ffmpeg: both shared and static builds are identically affected. Only ffmpeg.exe and ffprobe.exe crash, ffplay.exe doesn't. All run without crashing from within DW. All files require the UPX or writable .text section fix first. Crashes occur at 0177:bfa41c54 which is slightly different than for most other programs. http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-20140405-git-ec8789a-win32-static.7z http://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-20140405-git-ec8789a-win32-shared.7z zxtune: both latest (r3000) MINGW and MSVC builds are affected. Earlier builds (r2850) both run fine. Includes GUI and console programs. All console programs run without crash from within DW. https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/2850/mingw/x86/zxtune_r2850_mingw_x86.zip https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/2850/windows/x86/zxtune_r2850_windows_x86.zip https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/3000/mingw/x86/zxtune_r3000_mingw_x86.zip https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/3000/windows/x86/zxtune_r3000_windows_x86.zip

Of the plugins that autoload when VLC starts without argument here, those crash the app if they are not UPXed: .\plugins\access\libaccess_bd_plugin.dll 98.0 KB .\plugins\access\libaccess_vdr_plugin.dll 74.5 KB .\plugins\access\libdshow_plugin.dll 262 KB .\plugins\access\libfilesystem_plugin.dll 44.5 KB .\plugins\access\liblibbluray_plugin.dll 1.92 MB .\plugins\access\libstream_filter_rar_plugin.dll 39.5 KB .\plugins\access\libzip_plugin.dll 111 KB .\plugins\audio_filter\libequalizer_plugin.dll 48.5 KB .\plugins\control\libglobalhotkeys_plugin.dll 37.5 KB .\plugins\control\libhotkeys_plugin.dll 53.0 KB .\plugins\demux\libplaylist_plugin.dll 130 KB .\plugins\gui\libqt4_plugin.dll 10.6 MB .\plugins\lua\liblua_plugin.dll 290 KB .\plugins\meta_engine\libtaglib_plugin.dll 1.44 MB .\plugins\stream_filter\libdash_plugin.dll 692 KB .\plugins\stream_filter\libhttplive_plugin.dll 519 KB .\plugins\stream_filter\libsmooth_plugin.dll 59.5 KB And those don't crash VLC and get loaded fine: .\plugins\access\libdvdnav_plugin.dll 235 KB .\plugins\audio_output\libdirectsound_plugin.dll 27.0 KB .\plugins\audio_output\libwaveout_plugin.dll 30.5 KB .\plugins\misc\libxml_plugin.dll 1.19 MB .\plugins\video_output\libdirectdraw_plugin.dll 65.0 KB .\plugins\stream_filter\librecord_plugin.dll 14.5 KB

Thanks.

All files get compressed here using the frontend with UPX 3.07 and also with UPX 3.91 which I have updated to make sure it was not down to UPX version. Be aware that a plugin that does not get compressed might very well mean here that it won't load and hence some loss of functionality. I suggest you try to use UPX settings as per my screenshot above and see if it performs differently/better.

I am sorry but I am not going to apologize for uploading a 7z file that's perfectly compatible with 7-Zip 9.20, a version that's free for everyone to use, lightweight, causing no known problems and 100% compatible with vanilla 98/ME. Your whole rant makes very little sense to me and some parts of it none at all. I am not sure what has actually gotten to you here.

Thanks but let's rather call it the UPX fix and it would be nice if somebody could figure out why it works as there is certainly nothing "magic" about it.

I 'd suggest you build your own socket 939 system supporting AMD Athlon 64, Athlon 64 FX and equivalent Opterons running at up to 2.8Ghz. All those CPUs support SSE2, some support SSE3 too. Suggested high end motherboard with full 98/ME driver support: Asus A8V Deluxe (VIA chipset) MSI K8N Neo2 Platinum (nForce3 chipset) might be worth a look too. Add to that 2GB of RAM (limited to 1995 in system.ini) and nVidia serie 6 or serie 7 GPU with no more than 256MB of VRAM and you'll have a very cool little system for using WinME.

I made it with 7-Zip 9.31 Alpha. You should update your 7-Zip to at least 9.20, there is no reason for using 4.65 as 9.20 runs on stock 98/ME if I am not mistaken. And if I am mistaken, it runs on systems with KernelEx as this is what I am using. IzArc 4.1.8 (requires KernelEx) PeaZip (current latest, not sure if it requires KernelEx or not) Edit: Jaclaz beat me to it.

For the desktop machine you've always the option of installing an USB 2.0 extension card that's got drivers for 98/ME. But perhaps you could try adapting NUSB for WinME, stripping WinME files from it, adapting inf files and whatnot so that it becomes useable on any machine without drivers for you and everybody else after you.

I downloaded RegUtils.7z from Mediafire. Its md5 is 644BD3B6D12E3BF89C02316BB7AD9D3B and it unpacks just fine with 7-Zip, IzArc and PeaZip.

I've never had such a problem on any of my Windows ME systems. The obvious (if applicable): Have you installed the USB 2.0 drivers for your boards? Is USB 2.0 enabled in your BIOSes?

What is there to "fix" with USB 2.0 on Windows ME????

Just copy d3dx9_43.dll to your system dir and that's all you should need to do.

Mikl, I have tried EVR with MPC-HC (1.5.1.2903) which I hadn't done before and it's working fine here with EVR and EVR-CP. With EVR-Sync however Windows crashes as soon as a video is loaded and playback starts. Of all the players I am using MPC_HC is the only one to offer EVR-Sync as a choice of renderer so I can't test that in another player. What is this rendering mode about anyway? I could not find any information about it. And what's wrong with d3dx9_43.dll?

schwups, the two function logged by your kstub452 aren't handled by KexStub here and I have InitializeSListHead=f1 so none of those should be a problem. As I can't figure out something else I am attaching to this post my kstub822.ini for you to try but be aware that it's most probably not really up to date in terms of latest/best definitions for some functions. kstub822.7z

Doug, your observations about the copy overlay switch appear to be accurate, thanks the correction. As for VLC, I also compress the integrality of the plugins, if I only compress files in the root folder it crashes in Kernel32 for me too. In case this still would not work, I checked the UPX cli version I am using with the frontend and it's 3.07. VLC is in KernelEx default compatibility mode. And yes this is intriguing, I don't know why it works but it does (on most newer gcc compiled executable files apparently) which is very cool.

Try those below, actual defs may not be needed and, if not, those are very probably suboptimal so if you've got any of those functions already covered they should be OK as you have them. [Advapi32.dll] AddAccessAllowedAceEx=z5e [shell32.dll] SHGetKnownFolderPath=f4 [user32.dll] RealGetWindowClassW=f3 How did you get the plugin running in Opera 10, did you do a proper install of Java 7 or did you do it manually?

Sounds good schwups, my focus wasn't browser plugin at all as I don't really care but running standalone java programs so it's cool you're looking into that. I can run control panels of my portable JRE7 and portable JRE8 (both latest versions, u51 and b132 respectively) without problems by double-clicking on the respective javacpl.exe programs btw.

I suggest you write a program that make it possible to use multiple CPU cores so I could upgrade to a dual-core CPU and watch any 1080p video without problems for example.

Aren't programs compressed by UPX guaranteed to be 100% functional once they've successfully decompressed and the PE image is loaded in memory? The thing is I have a few programs that are able to load bigger data files on a freshly booted system than they can on a system that has been in use for some time and RegCon seems to be one of them. As this issue occurs when there is more than enough free RAM and no significant depletion of any free resources I can monitor I don't know what could be possibly the cause apart from memory fragmentation. I once read from a photoshop plugin developer that the maximum dimension of an image his plugin was able to process was dependent on the maximum amount of physically contiguous RAM the it was able to use. I did not believe it as I know an application memory space is virtual and actual physical location is managed at a lower level by the aptly called memory manager and that it shouldn't make any difference whether the RAM an application use is physically contiguous or not. I did not believe it also because when using his plugin I never found it could process a bigger image on a fresh boot than after several days of use and having opened and closed many programs in the meantime. So now I don't know what to believe about it as I have a few programs that exhibit a behaviour that would fit that. But perhaps there is an other explanation and I just can't figure it out.

I think jds' system.dat file was corrupt in some way. I've had registry files corruption undetected by scanreg a few times. As for RegCon, I can't think of a reason why the Japanese version would work better than the (rather poorly but overall understandable) translated one. I've processed registry dat files a few megabytes larger than the 12MB he reports many times without problems with both applications (translated RegCon and translated RegiStrip). Also, I think this program might be sensitive to memory fragmentation so, in case of failure that's not due to bad/ghost keys it may report, I'd suggest trying using it again straight after rebooting.

AFAIK the only tool that works is RegCon, it's been reuploaded several times but all links are apparently dead so here is a new one (bundled with related RegiStrip registry space analyzer from the same author): http://www.mediafire.com/download/2wx6fb9pscad3zl/RegUtils.7z

You can still get it here: http://www.sosej.cz/Software/Kompresni-nastroje/Upxfrontend/ (wasn't easy to find as it's quite old and homepage is gone). You don't need to use this one particularly btw, Guipex and probably many others would be just as convenient, I just happen to use this one most often out of habit.