jumper

Actually, it's very easy. Just hook up any WiFi modem and configure it via web browser.

My main 98se box still has stock IE5.0, so my Shlwapi section looks like this: [Shlwapi.dll] -- use IE8 -- IsCharSpaceA= ;ie8 PathCreateFromUrlAlloc= ;IE9 SHCreateThreadRef= ;ie8 SHRegisterValidateTemplate=r0x78s2 r120s2 ;upgrade to IE5.5 #67 ShellMessageBoxA= ;IE9 StrChrNW= ;ie8 StrCmpLogicalW=>:StrCmpIW ;upgrade to IE5.5 StrStrNIW= ;ie8 This is one of the reasons I'm considering making IE5.5 a requirement. Instead of forwarding, my current recommendation is to use some of the files from IE5.5, 6, or even 8 (as I do) as additional "helper" modules via KernelEx\KnownDLLs: REGEDIT4 [HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs] "advpack" ="IE8\\advpack.dll" "ieframe" ="IE8\\ieframe.dll" "iertutil" ="IE8\\iertutil.dll" "jscript" ="IE8\\jscript.dll" "msrating" ="IE8\\msrating.dll" "normaliz" ="IE8\\normaliz.dll" "occache" ="IE8\\occache.dll" "shlwapi" ="IE8\\shlwapi.dll" "urlmon" ="IE8\\urlmon.dll" "xmllite" ="IE8\\xmllite.dll"

> RAM: 1024MB Out-of-memory errors with this much ram is a classic problem. Between system ram and graphics ram, you have too much! The solution is usually to reduce the amount of ram. Can someone please add details or links to the instructions how? (TIA)

Sorry for the delay, but here is a new BCrypt.dll I wrote three days ago with a fully functioning BCryptGenRandom: From http://www.geocities.ws/jumper: BCrypt.dll replacement library (with C source) [7z] BCrypt.7z - 4KB (C) BCryptGenRandom calls RtlGenRandom (aka SystemFunction036) as implemented by the KernelEx project.

Please (enable logging and) check kexstubs.log and report the definitions that are being used. In this thread we can discuss tweaking them to possibly improve results; also which APIs need to be implemented in KernelEx.

[DLL replacements] BCrypt.dll=IPstub.dll [IPstub.dll] BCryptGenRandom=c4

The "something to test" that still hasn't been tested is an image embedded as multipart MIME. It is probably referenced locally and prefixing a base href--even just a protocol--might break the reference. If so, then each "//" will need to be individually prefixed with "http:".

> In the HTML source code of the e-mail the style code itself is not processed and leads to delay I think this is not cause-effect, but rather two effects of the "//" cause. The "x/" substitution fixes that. > is possible in the line (style) ".woff" to recognize and remove this line[?] Yes, but it might not be desirable to lose all other formatting in that style tag. I think the "x/" substitution alone will solve the server-delay problem but at the cost of lost external formatting and/or content. In the Sky case, it also avoids the woff font format issue as an added bonus. The base-prefix method or inserting "http:" before each "//" are better solutions. If the woff font format really is a problem for IE8, we can fix that next (Bugscreen may already consider it "crud").

> The installer always gives me some dll errors This is better than non-dll errors. Details, please. > how to run Office 2013 somehow on Vista? Trying installing it on Win7+ and copying the files to Vista. Be running a Registry monitoring app while installing so you can also export and copy those entries as well. Check for an Installer Log file that lists all the changes made to the system. (@Everyone: is there a Tutorial or FAQ somewhere on the 'net that explains this process?) > Is there any hack or edit? Probably not. Do you have all of the Vista service and upgrade packs installed?

Replacing ".woff" with ".woxx" will prevent the font file download. Replacing '"//' with '"x/' will prevent the delay but also the style sheet from downloading. In my experience, a "<base href=...>" tag works anywhere until EOF or overridden. Prefixing should work just fine unless maybe there is a MIME multipart embedded image. Something to test. I stumbled upon a description of Bugscreen two days ago and it did look very promising, but there was no download link. I choose sleep over search. Unfortunately, the file bugscreen_killist.txt seems to be the only configurable option of interest. Can you post that file?

Thanks for testing the files. The .cpp files are the C++ source files I modified before building each .dll. I included them for anyone to compare the changes I made against the original. Only the .dll files need to be installed in the Plugins folder. I found Eudora Light 3.0.5 on a backup CD from 2001, copied it to my HDD, removed the read-only attribute from all files, and fired it up. In two blink of an eye, it connected to my old NetZero account for the first time in over 17 years and displayed just one new service email--dated this morning! The Plugins folder contains two of the samples: Sort, UpprLowr (plus several others). I will switch to modifying the UpprLowr (EMS_VERSION 3) and test as I go.

I just saw the DW results (both), and because there are only warnings, it should at least load and begin to run. Try DW again and if there are still just warnings, press F7 and start Profiling. Edit: Also just noticed several files with Link Checksum in red. Those files appear to be corrupt. On XP invalid checksums might prevent loading (or maybe just in drivers?).

Great! I'll add stubs for these in an upcoming Core update.

Sorry, you can't do what you're trying to do. :( Imports from Kernel32.dll have to come from Kernel32.dll... ...unless you redirect them _all_ to mod.dll: [DLL replacements] KERNEL32.dll=mod.dll And then mod.dll has to handle _all_ Kernel32 APIs (it can export-forward them back to Kernel32.dll, however).

I thought we had determined that the problem was DLLs using the TLS data type (resulting in a TLS directory entries) instead of calling the TLS functions (which work just fine). I think you are referring to this post: Vista's explicit-load-of-DLL's-that-use-implicit-TLS problem might be solvable by simply adding the delayed dependency to the import table. I'm working on adding support for this, plus automation and more to ImportPatcher. and this post: If we add a large implicit TLS data section to Kernel32.dll, that should solve the thorny reallocation problem. Then LoadLibrary just needs to properly initialize the TLS selector index.

You might find something useful here: X230 USB BIOS options discussion * Disabled USB 3.0 from BIOS * upgraded the BIOS to version 2.62 * USB UEFI BIOS Support : Enabled * UEFI/Legacy Priority : Legacy First

https://web.archive.org/web/20000820075831/http://www.iarsn.com/tskinf21.zip v2.2 and v3.0 are good substitutes, but with bigger footprints: TaskInfo History

My experience has been different and having the source code helps. A version check should be easy to fix; new dependencies might expand build requirements; other scenarios are unlikely.

> But (I know I'm repeating myself) if one simply inserts "https:" in front of the //'s at the start of those three URLs at the end of the .htm file... or > prefix buffer with "<base href=http:>" instead of filtering and > in fact, while at it, it could even, you know, block ads.... There are a number of easy solutions if we can just get a plugin to work. There isn't a code sample for simple filtering; there are inconsistencies across code samples; documentation is (too) detailed while lacking context.

ImportPatcher does patch and/or report a few things in the headers other than just imports, so it'll be easy to also detect TLS directory entries in DLLs (not EXEs) and zero them if requested. Do these Firefox problem DLLs export any common functions (like plugins do) that can be used to identify them?

> ... gecko > 49 ... If 45 and 49 both still use mozjs.dll, perhaps a 49 SSE build of just that dll could be used with the full 45 SSE build?

> And here is the package (finally!): > http://www.geocities.ws/jumper/EudoraPlugins.7z - 39KB Please test the original sort32.dll and my mod 3a.

I found the SDK and have developed some test plugins. I'm just now seeing the last 27 hours of posts, so my tests are a bit dated. Here is the readme from the package I'm preparing: And here is the package (finally!): http://www.geocities.ws/jumper/EudoraPlugins.7z - 39KB

Sounds like you should be updating GDI32.dll from sp3 to sp4. There may also be a GDI.exe (or similar) that needs to match. GdiDrawStream is also supported by BWC's KDW Wrapper. https://web.archive.org/web/20160620154132/http://www.msfn.org/board/topic/175185-list-of-web-browsers-that-work-on-windows-2000

Screen flashes can occur when the display resolution or color depth are modified. Make sure the desktop is already in a mode preferred by the app (usually true-color). Power events can also cause a flash. Check Monitor Properties (under Display Properties -> Settings -> Advanced -> Monitor or similar) and uncheck "Reset display on suspend/resume."