jumper

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!

And add the following to stubs.ini. No registration appears to be necessary. [Kernel32.dll] GetFileSizeEx=f2e120 ;D3DX9_43.dll 9.29.952.3111

I think the key name for Windows 2000 is "ShowInfoTip" Windows 2000 has infotips for some programs and folders. You can disable this feature in two ways.

Good link. Opera 15 has been much maligned for using the Blink UI.The Chromium Embedded Framework (CEF) looks interesting, however: Architecture, Downloads Release build of the cefclient [sample] application for 32-bit Windows using CEF3 version 3.1650.1562. Requires Windows XP SP3 or newer. Jan 12, 2014 17MB Aviator.msi is ~60MB, by the way. I'll continue trying to get these to run on 98; maybe someone can try them on XP or 7 to see if they're worth the effort? I've also been working with several Chromium portables in recent weeks--I can get them to load in 98, but they crash immediately. Haven't tried Opera 15 yet.

Don't blink now, but guess what I found when I opened the Aviator.msi package with 7zip?

Claims to support Windows 98, but doesn't. So can we believe any of their claims?

I searched for and was able to find Dxva2_x86.dll : + 5.00 (vista_rtm_wcp.061020-1904) + 6.0.6001.17014 (lh_tools_devdiv_wpf.071009-1043) + 6.0.6002.18084 (vistasp2_gdr.090806-2338) and Evr_X86.dll: + 5.00 (vista_rtm_wcp.061020-1904) + 6.0.6001.17014 (lh_tools_devdiv_wpf.071009-1043) Without needing to add any new Kexstubs definitions, I can load all three versions of Dxva2_x86.dll in any KernelEx compatibility mode. The two Evr_X86.dll versions both load in all 9x modes, but call NtOpenFile (no functioning definition yet) in all NT modes.

If from day one they used Win9x-compatible tools, yes, it would have worked on Window 9x out-of-the-box. But it also would have been a much more difficult project to include all the features that are now built into later versions of the Windows OS and API. I haven't looked at the source code, but they are either writing directly to the Windows NT API or to a framework with API requirements. Either way, changing to a Win9x-compatibile compiler now is not an option. I haven't written a 16-bit Windows app in ages, but I still could. Trying to get it to have the look and feel of a "modern" 32-bit app would be a lot of work, however. Design choices usually involve trade-offs and difficult decisions. Using modern tools for new projects is completely understandable.

Are there any special CPU/GPU or other hardware requirements? Suggested API definitions to try (and what also needs them): >[Advapi32.dll] >GetTraceEnableFlags= GetTraceEnableFlags=z1 ;Chrome.dll >GetTraceEnableLevel= GetTraceEnableLevel=z1 ;Chrome.dll >GetTraceLoggerHandle=t1e GetTraceLoggerHandle=z1e0 >RegisterTraceGuidsW=f8 RegisterTraceGuidsW=z8 ;Chrome.dll >TraceEvent=f3 TraceEvent=z2 ;IE7 >UnregisterTraceGuids=f2 UnregisterTraceGuids=z1 ;Chrome.dll >[NTDLL.DLL] >RtlInitUnicodeString=>Kstub822:IAS RtlInitAnsiString=>Kstub822:IAS RtlInitUnicodeString=>Kstub822:IUS Note: 'f' and 'z' are functionally the same, but I use 'z' for ERROR_SUCCESS instead of 'f' which looks like "fail"

The power supply is dead. I've had several go out over the years. If any case fans are attached directly to the psu, that would confirm it.

In case anyone donated and hasn't heard yet: CNN - 6 days ago: Kickstarter, a popular crowd-funding site, urged users to change their passwords Saturday after announcing that it had been hacked.