jumper

> directx 8.0b wasn't ever a full update There is no 8.0b. Perhaps you're thinking of the 8.1b update. 8.0a is the last for Win95 (but it might be possible to mod 8.1 into working). First you need choose your DirectX Game Engine for Win95. The requirements will probably be the following: * Install MSVC 6 (VS98) (or maybe MSVC5/VS97 or MSVB6) * Install the Win95 Platform SDK (if not included with VS) * Install the DirectX 8.0a SDK * Install the Game Engine SDK (Or modify DX8 samples) VSE2003 might work for development (depending upon platform), but the runtimes might not (on W95; if not, static link instead). Avoid .NET unless the Game Engine uses it. Win95 DDK is not needed.

Microsoft has shut down the Search Assistant. "ie.search.msn.com" now redirects to "bing.com" which doesn't support "srchasst\srchasst.htm" (or "srchcust.htm"). Scan your registry for the string "ie.search.msn.com" or "srchasst" and replace that URL with a new one of your choice such as "http://ie.search.yahoo.com/{sub_rfc1766}/srchasst/srchasst.htm". See: &tab; answers.yahoo.com/question/index?qid=1006043010329 (Alternately, you can install some mid-2000's malware and let it hijack the search assistant for you!)

So as of 8.1, GetVersion, GetVersionEx, and VerifyVersionInfo are deprecated in favor of the new Version Helper APIs: So Windows is now doing with a manifest just what KernelEx does with compatibility modes. Okay, got it! Can you run the test again with just the Win8.1 manifest entry? Also Win7? That would complete our post-XP version gathering. Support for manifests and the Version Helper APIs will be added to KernelEx todo list.

So Win10 1809/17763.316 and 1803/17143.590 are both reporting the same (incorrect) build number: 23F0 hex = 9200 dec In comparison: WinXP SP3 build 2600.xpsp_sp3_qfe.180912-0606 (with POSReady patch) reports: A28 hex = 2600 dec What is MS thinking! Are 17143 and 17763 updates to an earlier 9200 install?

The Lite versions don't seem to support the plugin features I need to test, so development is on hold. If you are not on a LAN, I like the idea of disabling any LAN services. There also might be a registry setting to reduce the timeout for unresponsive LAN servers. If you are on a LAN, perhaps you can add a server named www.sky.com as an alias to your local drive (via Network Neighborhood) or redirect it (maybe via LMHOSTS) to 127.0.0.1/localhost. Maybe: 127.0.0.1 helpforum.sky.com 127.0.0.1 www.sky.com

When DirectX is installed, it become available to apps and drivers that know how to use it. The "System" uses GDI for rendering, not DirectX. GDI can be accelerated by the video drivers. Taking advantage of an updated DirectX would mean updating the video drivers. DirectX 8.0b (the software) is unlikely to even have any 2D improvements. A newer graphics card with hardware support for Direct 8 or later should already have any superior 2D capabilities incorporated into its drivers.

> is it necessary to have ieframe.dll as I don't see how it would load if it were called for? If it is called for then it probably is necessary. And it will load if all dependencies are available. Unfortunately KernelEx doesn't currently support selecting from multiple versions of IE. The use of IE8 files is a work-in-progress--an attempt to upgrade browsers that (can) use the Trident rendering engine up from IE5/5.5/6 to IE8. Probably now a case of "too little, too late." :( Because some websites block IE6, I recommend installing IE5.5 instead. You do not need to use any of the IE8 files if you don't want to. >> SHRegisterValidateTemplate=r0x78s2 r120s2 ;upgrade to IE5.5 #67 > The SHRegisterValidateTemplate=r0x78s2 r120s2 can you explain? Comments actually start at the first space, so the definition is "SHRegisterValidateTemplate=r0x78s2" and the comment is "r120s2 ;upgrade to IE5.5 #67". Hex 0x78 is equal to decimal 120. Kexstubs version 822 and earlier contain a parsing bug the requires return values to be specified in hex. "#67" means "see discussion in post #67." Because posts are no longer numbered, this is now the 7th post on page 5 (4*15 + 7). > Are they functions without string references ie N/A? Please read the documentation at the top of stubs.ini. > Xmllite and normaliz should not be a problem should they? Use them straight in the system? I have had Normaliz picking up before. I highly recommend against putting non-9x files directly into the System folder. Apps that can use these files also need KernelEx, so put them in a KernelEx subfolder and reference them via HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs.

@MrMateczko - Thanks. For Win10 we'll probably eventually want each of the major builds even though Kex will probably never really have any significant support for that OS. The biggest need is for x86 versions of XP0,1,2,3; Vista0,1,2; and Win7, 8, 8.1. @Goodmaneuver - Wrong thread. Double-check your spelling and syntax, add missing DLL name, and repost in the Kext: DIY thread.

To aid in adding support for more compatibility modes, I wrote the following tool for everyone to help in gathering Windows version details: From geocities.ws/jumper: GetVersion — Display and copy to clipboard results of GetVersion, GetVersionExA, and GetVersionExW: [7z] GetVersion.7z - 4KB (with C source) For stock Win98se, the output of GetVersion.exe looks like this: GetVersion: 0xC0000A04 GetVersionExA (OSVERSIONINFOA*): dwOSVersionInfoSize 0x00000094 dwMajorVersion 0x00000004 dwMinorVersion 0x0000000A dwBuildNumber 0x040A08AE dwPlatformId 0x00000001 szCSDVersion[128] "a" [61 00 00 00 ...] return TRUE GetVersionExA (OSVERSIONINFOEXA*): dwOSVersionInfoSize 0x0000009C dwMajorVersion 0x00000004 dwMinorVersion 0x0000000A dwBuildNumber 0x040A08AE dwPlatformId 0x00000001 szCSDVersion[128] "a" [61 00 00 00 ...] wServicePackMajor 0x0000 wServicePackMinor 0x0000 wSuiteMask 0x0000 wProductType 0x00 wReserved 0x00 return TRUE GetVersionExW (OSVERSIONINFOW*): dwOSVersionInfoSize 0x00000114 return FALSE GetVersionExW (OSVERSIONINFOEXW*): dwOSVersionInfoSize 0x0000011C return FALSE gv=0xC0000A04 gvex=4,A,40A08AE,1,a,0,0,0,0,0 I've also tested it on ME and XP/sp3. The last two lines will be used in Kexbases now and Core.ini later. Please post the last two lines of your results and report any functions that return FALSE so we can have a complete set of results. Thanks!

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