jumper

The official download page still lists XP sp3 as supported. Linux and Android versions are also available, so Linux in a VM or a cheap Android tablet are options.

This script will attach the preloaded images to the page. Use as a bookmarklet or paste directly into the URL bar. Tested in Firefox 2 and IE 5: bookmarkletjavascript:for(i=0;e=document.MM_p[i];i++)e.width=0,document.body.appendChild(e);eThen I used UnMHT Ver.5.7.7 (last for FF2.0) to save with all images as MHT. IE 5 only saves images refered to by the original HTML; scripted images (like ads) don't get saved.

A bookmarklet should be able to add references to the webpage for files passed to MM_swapImage, allowing them to be saved into the MHT.

If the patch is simple, this might work: Compare the patch to the original, then use a hex editor to make the same changes in the Japanese version. Or compare the Japanese version to the original version, then use a resource editor to make the same changes to the patch.

>I'm currently running a 450MHz Pentium III with 256MB of RAM. That's probably not fast enough to get smooth and synchronized audio and video unless you use one of the older Flash versions such as 8 or 9..but they can't show the new controls. >purchased movie on youtube- it crashes flash player (seems like any version) after about 20 seconds. Illegal Instruction or Page Fault? >Latest flash (v14) runs fine in Opera 12.02 with KernelEx and KxStub. And it runs better and smoother than previous versions which were quite buggy IMO. Wow! What CPU and how much RAM are you feeding it? >Problem with html5 videos is that no browser running on 98/ME supports the VP9 codec which YouTube now uses for those if I am not mistaken. Opera 10.63-12.17 uses GStreamer: We might be able to transplant the Opera 12.17 GStreamer dll's into 12.02, 11, or 10. Or rebuild what we need from source.>Are there any people who are testing newer browsers on 9X? Yes. Iirc QtWeb works. Also GreenBrowser 6.4. I just tested Qupzilla 1.66 last week and found that it suffers from the same (probably fixable) stack-leak crash at startup as 1.44. I've also tested Opera 12.10 and 12.16, FirefoxPortable_24, Palemoon-Portable-8.0, Seamonkey 2.9 and 2.14, X-Chromium_16, Midori-0.4.6, K-meleon 1.6b2, Safari 6.0.5, IceDragon, Flock, Arora, Aviator, and others (like FastestWebBrowser). The IE7 dll's partially work--I'm hoping to get them working with a light-weight frontend such as GreenBrowser. >Live with the occasional failure -or- upgrade the OS that will allow for a Browser that supports it. Or help develop a solution. >It may be to vc++ not working on Win 98. With Kexstubs, the MSVC 9, 10, and 11 runtimes all load on Win9x. I have seen no reports of them loading and then not working correctly.

C

Here's the core function. Full source attached below. (The mbf function is just a printf into a MessageBox.) void doFile (LPSTR szMod) { LOADED_IMAGE li; UINT bPatch = 0; iFiles++; //mbf (szAppName" - %u:%u:%u - %s", iFiles, nFiles, nPatchedFiles, GetLFN (szMod)); if (!hwndPB) return; // only count on 1st pass swtf (szAppName" - %u / %u : %u - %s", iFiles, nFiles, nPatchedFiles, GetLFN (szMod)); SendMessage (hwndPB, PBM_STEPIT, 0, 0); Sleep (40); if (!MapAndLoad (szMod, NULL, &li, FALSE, FALSE)) return; do { //if (li.FileHeader->OptionalHeader.MajorLinkerVersion != 2) break; //if (li.FileHeader->OptionalHeader.MinorLinkerVersion < 22) break; if (((PUINT)(li.Sections[0].Name))[0]=='xet.' && ((PUINT)(li.Sections[0].Name))[1]== 't' && ((PBYTE)(&li.Sections[0].Characteristics))[2] && ((PBYTE)(&li.Sections[0].Characteristics))[3]<0x80) { //mbf ("%s\n\n.text section is now writable", GetLFN(szMod)); ((PBYTE)(&li.Sections[0].Characteristics))[3] |= 0x80; bPatch++; } if (li.NumberOfSections > 2 && ((PUINT)(li.Sections[2].Name))[0]=='adr.' && ((PUINT)(li.Sections[2].Name))[1]== 'at' && ((PBYTE)(&li.Sections[2].Characteristics))[2] && ((PBYTE)(&li.Sections[2].Characteristics))[3]<0x80) { //mbf ("%s\n\n.rdata section is now writable", GetLFN(szMod)); ((PBYTE)(&li.Sections[2].Characteristics))[3] |= 0x80; bPatch++; } } while (0); if (bPatch) nPatchedFiles++, UnMapAndLoad (&li);} // doFilegccfix.src.7z

For the last week, I've been testing CloudMe_182. It suffers from the same problem as vlc-2.1.3-win32.7z and slightly more. In addition to needing the .text section protection changed to allow writing, it also needs the .rdata section changed as well. Upx391 didn't like the CloudMe_182 PE files, so I finally wrote a tool called gccfix to do the patching. It is very quick and processes individual files or whole directory structures. gccfix patches in-place, so backup first or keep the original installer or archive. gccfix.7z

Good work, everyone. I'd chime in more, but am having web access difficulties. Development on many fronts continues....

It's not the compression, it's the write privilege on the .text section (the first two sections in a UPX-compressed file are both writable): I plan to add an option to ImportPatcher to automatically fix the app and all dependencies. edit: more clarity

So mobile view is automatic, based on user agent? Thanks.

What mobile view?

Google: "Dell truemobile 1300 win9x" First two links provide the needed info: wpc54g_driver_utility_v1.21.zip ftp.linksys.com is down, so Google: "wpc54g_driver_utility_v1.21.zip" and follow links to Modem-help or DriverGuide. File is 8.3MB.

1) Make sure you're using an UDMA-rated cable (with more/thinner wires) 2) Google: "site:www.msfn.org udma cable-select"

Dialog #1 in Kernel32.dll

A year ago in http://www.msfn.org/board/topic/157173-kext-diy-kernelex-extensions/page-5#entry1026129 I suggested some definitions that might get SM2.9.1 working, but have seen no follow-up. SM2.6.1 has been working (with caveats) for several years. SM2.0.14 is the last to function fully according to http://kernelex.sourceforge.net/wiki/SeaMonkey. Googling "Seamonkey 2.1 changelog" I quickly got to http://www.seamonkey-project.org/releases/seamonkey2.1a1/changes It appears that SM2.0.5->2.1a1 involved a migration "from Fx3.5x to Fx3.6x" KernelEx and debuggers don't like each another, making debugging of these bookmarks, history, printing, and other modern issues very difficult.

web.archive.org/web/*/http://download.microsoft.com/download/winntwks40/Utility/4.71.1015.0/NT4/EN-US/WIN_DEPLOY.exe "Saved 10 times between April 14, 2002 and March 20, 2006." Until your post, I hadn't seriously considered checking Wayback 'cuz MS has blocked it for years. Apparently, 2006 is when they began the blocking. This is good news for those times we're looking for really old MS stuff. The newer things MS is now taking off its sites won't be available from Wayback.

I'm working (slowly) on a general solution that will help for all 32-bit Windows versions.

WIN_DEPLOY.exe

Interesting information that provides a few more details on what went wrong, but nothing on why (or where). We already knew there was a loader problem. Also doesn't explain why VLC 2.1.2 works and VLC 2.1.3 doesn't (same section definitions). Can you ask him to do the same analysis for the VLC 2.1.2 libvlccore.dll? Also the UPXed and patched .text versions. And what tool is he using to get the memory page details? Thanks.

This is great, loblo. The first group all have 32-bit alignment in the .rdata section; the second group, 4-bit alignment. The first group all double-GPF when directly loaded with LoadLibrary, the second group don't. Changing the reported alignment bits doesn't help, however. Also, the VLC 2.1.2 plugins all load without error no matter what the alignment. Changing the .text section to be writable or UPXing the problem files both work.... UPXing is still the easiest/best work-around.

Doesn't work. It will be printed the first page which firefox "sees" when accessing C:/temp.htm, and this is a blank page. Maybe it could work if firefox somehow "waits" some seconds before printing.When the delay is zero, the page load isn't complete until after the meta refresh. Perhaps you have meta refresh disabled in Options? Put some extra text before the meta tag and also try -print "file:///C:/temp.htm" to make sure temp.htm is getting loaded.This should also work for temp.htm, but requires javascript to be enabled: <script>document.location="http..."</script>You could also write the URL into pref.js at user_pref("browser.startup.homepage", "http...");Make sure that When Firefox starts: Show my homepage [no user_pref("browser.startup.page", 0);]Then launch Firefox: D:\Programme\Mozill~2\firefox.exe -print -printfile C:\zzw.png

I've been investigating the "why" and part of the answer is obvious: something about the new GCC linker output is incompatible with either the 9x/Me or KernelEx loaders. UPX has its own two-stage loader that is compatible with both 9x/Me/Kex and GCC and that is how UPXing solves the problem. I compared VLC 2.1.2 and 2.1.3 and Libvlccore.dll was the only dll that acted differently for me in LoadLibrary between versions (2.1.2 loaded, 2.1.3 GPF'd twice in the init routine) The two writes at 6A66E3CC and 6A66E3F0 are at the end of the Read/Write .data section, but somehow the loader set the permissions for those addresses to Read-only. Hexing the .text section permissions to enable writing fixed the GPF's and allowed the 2.1.3 Libvlccore to load successfully. This indicates the (KernelEx-modified?) loader is allocating memory incorrectly. While there are a number of differences (bugs) in the GCC 4.2.8 output of VLC 2.1.3 versus 2.1.2, I haven't been able to find the change that is triggering the problem. I need more (and smaller) examples. Has anyone confirmed that the plug-ins really needed to be UPX'ed? If so, I need to know (some of) which ones do and (some of) which ones don't so I can compare them across versions. Thanks.

It would nice if Firefox supported @params, but then it doesn't seem to support -print or -printfile either. There is an extension for printing, maybe there's one for an argument file as well? You could try "-print file:///C:/temp.htm" where temp.htm contains a meta refresh to the full URL: <meta http-equiv="Refresh" content="0; URL=http://google.com">

Sorry for continuing off-topic, but my blood is boiling. Until jaclaz' last post, Nomem was the only one here showing any sense at all in this matter: I have both 7-zip 4.62 and 9.20--4.62 is installed/integrated; 9.20 is a SendTo when needed. 4.62 is lighter, more compatible, and usually compresses tighter than 9.20 9.20 is for when silly folks used it to compress by accident (assuming that newer is better?) Classic Zip will always be the standard for compatibility and its compression is usually more than good enough. I've found my Zip attachments to be slightly more popular by number of downloads than my 7z (v4.62) files. Anyone who uses an alpha version to create a file for distribution should be apologizing profusely when it can't be opened (not making excuses) and reposting ASAP in a format the intended recipient is known to have access to. To conclude: please compress 7z files with v4.x, not 9.20, and never with an alpha version. TIA!