jumper

Get a wifi router that also has a client mode, then connect it to the PC via the nic. No driver needed. Configure the router with your web browser. I'm online right now using an Airlink101 AP431W in this way. Edit: Bridge mode can also be used if the client router's chipset matches that of the wifi access point it is connecting to.

>Original system files should not be replaced by stubs. Agreed! Fortunately, the KernelEx version (written by Tihiy, not Xeno86) is full-featured, not stubs. The three key functions in MSIMG32.dll are: * AlphaBlend * GradientFill * TransparentBlt Tihiy's version (7.5KB) contains nearly complete implementation of all three functions and fixes visible rendering problems that can be seen when some apps use the standard SE or ME versions. The XP version [5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)] is smaller (4.5KB) because it passes most of the work to XP's version of GDI32.dll (GdiAlphaBlend, GdiGradientFill, GdiTransparentBlt--not available in 4.10.1998/4.10.2227 for SE) with just a bit of modification to AlphaBlend. The SE and ME versions are larger (52KB), perhaps because they are unoptimized, debug versions. If anyone knows of (or wants to write) a test app to compare MSIMG32 feature compatibility, fidelity, and speed, we could determine whether Tihiy's version is indeed the best to use globally.

Yesterday I took a look at that 24Mar2012 version of ComDlgEx.dll and think I know what is going on--that SumatraPDF 2.2 is now passing real unicode strings to PrintDlgExW instead of multibyte strings. The 24Mar2012 version of ComDlgEx is actually the best in that it has real Unicode support for PrintDlgExW. But it didn't work with KernelEx via Kexstubs because of the way KernelEx uses Unicows. So the ComDlgKx.dll is dumbed down slightly to work with KernelEx and doesn't work with what S'PDF2.2+ is now doing. Fortunately I've learned a lot since last March. I should now be able to produce a better ComDlg32 wrapper that will work both stand-alone and with Kexstubs along the lines of the IpHlpApi wrapper I've been working on recently. I'll post an update in Printing with KernelEx 4.5.1 when I can.

In your BIOS, look for a setting that will allow you to use slower timings on the RAM. e.g. increase the CL from 9 to 10; or decrease the speed from 1600MHz down to 1333MHz, etc. You might also be able to increase the voltage from 1.5v to 1.55v (or more) if you have good cooling. If you don't have good cooling on the RAM sticks decreasing the voltage might actually make them run more stably.

Nomen, if Opera is running in KernelEx's Win2K mode, then it is using the 5.00.2218.1 (KernelEx special version) from your Windows/KernelEx directory. Only apps for which Kex is disabled entirely will use the Windows\System version. The KernelEx special version doesn't seem to have any non-standard dependencies, so you might be able to put it into Windows\System for use by non-Kex apps.

Welcome to MSFN, roscoegrable. While KernelEx might be able to help with driver installers, it doesn't help with the drivers themselves. Since your printer problem isn't KernelEx-related (yet), I suggest starting a new topic in the Windows 9x / ME subforum. You should also look here first for a good idea from jds that might work for you.

Drop the RAM to 512MB until you get SE installed. Then you will have multiple options to get it back above 1GB. (see stickie topic about running with >1GB, etc.) If the HDD/controller is SATA, you'll probably need to look for a compatibity mode for it in the BIOS.

I've happily followed all the activity here and in related topics over the last few days, but have been a bit busy. It seems there is much energy in 2013, and much to do! I'll catch up on responding to each issue later tonight, but for now here are some new stub definitions to verify: ; Remote Access Service Functions (Windows) [RASAPI32.dll] RasGetAutodialAddressW=t5 RasGetAutodialEnableW=t2 RasGetAutodialParamW=t3 RasSetAutodialAddressW=t5 [;RASDLG.dll] --- see Lz32 --- RasDialDlgW=f4 ;needs error set in struct RasPhonebookDlgW=f3 ;needs error set in struct ; Authentication Functions (Windows) [secur32.dll] AcquireCredentialsHandleW=t9 DecryptMessage=t4 EncryptMessage=t4 GetComputerObjectNameW=z3e120 GetUserNameExA=z3e GetUserNameExW=z3e InitSecurityInterfaceW=z0 InitializeSecurityContextW=t12 LsaEnumerateLogonSessions=t2 LsaFreeReturnBuffer=t1 LsaGetLogonSessionData=t2 QueryContextAttributesW=t3

MiKl> SUNBIRD verursachte einen Ausnahmefehler 03H in Modul KERNEL32.DLL bei 0187:bff768a1. A Google search for "03H KERNEL32.DLL bff768a1" led me to this post by jds, so clearly the Active Context (*ActCtx*) stubs are not working and need to be removed. SAP GUI for Java will surely break for jds when he tests with the "new" definitions because of this regression. Also, make sure you have the Kex default in Core.ini [ApiConfigurations] set to "default=2" (WIN98). default=5 is incorrect. Your system seems to have mismatched msvcrt DLLs or other DLLs used by Sunbird that are causing the problem, not Sunbird itself. If your default is already at "2", please disable KernelEx extensions completely on Sunbird. > After closing the error box another message appears saying that NEGOTIAT.DLL is missing. This has to do with Directory Services. Maybe Sunbird is trying to access Outlook? This doesn't seem to be related to Kex or Kext. > When using the new defs Sunbird and OpenOffice crash no matter if iphlpapi 3 or 4 is 'called'. Is this the correct term ? "Called" is okay; "active", "used", "being used" might be better. The Active Context stubs seem to be the problem, not iphlpapi4--this is good. >Commenting out the msvcr... sections seem to have no positive effect on my system. Okay, thanks. It now looks like iphlpapi4 is probably okay; the problem seems to be the ActCtx definition regression. I'll correct post #116

Thanks again to everyone for testing. It seems I've make too many changes all at once and it's not clear where something has gone wrong. @MiKl: Sunbird 0.5 (zip version) does not require KernelEx (Depends and IP36 both give it a clean bill of health). It runs fine in 98SE for me with Kex disabled or in any mode. It does link to Iphlpapi.dll but has no problems with iphlpapi4 using either the Kexstubs or local copy method. Using the local copy method I can see in a process viewer (TaskInfo2000) that both the original and wrapper are loaded. Questions: Are you using the new definitions? Are you using the Kstub or local-copy method? "Crash" is extremely vague--can you provide some details? @schwups: "...IpHlpDll Entry not found (7b340000 0)" is my debug message from the DLL startup function as the load is about to fail. 7b340000 is the address returned by LoadLibrary for C:\Windows\System\iphlpapi.dll and 0 is the address returned by GetProcAddress for ??? (silly me for not including the API name in the debug message ). It appears from the log that it actually loaded successfully on the first call to GetAdaptersAddresses, then failed on the second call--this could be because it follows a call to CreateActCtxW (that has caused trouble in the past) or something to do with how KernelEx hooks GetProcAddress. Try commenting out Kernel32:CreateActCtxW (and rebooting); if that doesn't help, please try the local-copy method. @jds: Can you test using the Kexstubs method (clear the KnownDLLs entry and use the new definitions)? It looks like the global- and local-copy methods might be immune to something that is ailing the Kexstubs method. For anyone experiencing R6034 runtime errors in OpenOffice or other apps, try commenting out the Msvcr90 and/or the Msvcr sections-> "[;Msvcr90.dll]", "[;Msvcrt.dll]". [ reference1, reference2 ] If the three of you can confirm that apps that worked with iphlpapi3 and older definitions also work with iphlpapi3 and the new definitions, that will isolate iphlpapi4 as the problem. If modifications to the new definitions are needed to get iphlpapi3 to work again, perhaps iphlpapi4 will also work.

Ktree9 has been posted. I was over-thinking the sorting thing. The solution was to do all inserting at the end, then make one call to TreeView_SortChildren for each group once the inserting was done. Load time is now less than one second !

I, too, was able to run SumatraPDF 2.2, but printing didn't work (page fault). I didn't install, but ran the 7-Zip-extracted version as usual. 2.2 is loading very fast once again like 1.9 did (2.1 was much slower to load). BTW, printing works in 1.9 and 2.1 with the help of the updated COMDLG32.DLL.

I vote to leave it here. A more general SATA<->IDE topic can be started in Hardware that can point back to this one for reference.

SeaMonkey 2.0.14 is an W2K-compatible version; SeaMonkey 2.14.1 is the latest XP+ version, is not W2K-compatible, and is NOT a minor upgrade to 2.0.14! I suggest trying 2.6.1. It should work with the new Kexstubs definitions. After that, try 2.9.1 -- it is the last W2K version. ImportPatcher.37 reports the following for SeaMonkey.exe and plugin-container.exe: ... [DLL replacements] RASDLG.dll= [RASAPI32.dll] RasGetAutodialAddressW= RasGetAutodialEnableW= RasGetAutodialParamW= RasSetAutodialAddressW= [RASDLG.dll] RasDialDlgW= RasPhonebookDlgW= ... Thus it requires these additional Kstub definitions for SeaMonkey.exe and plugin-container.exe: [Lz32.dll] --- all API's in functions that use KnownDLLs to forward to LZ32 --- RasDialDlgW= RasPhonebookDlgW= [RASAPI32.dll] RasGetAutodialAddressW= RasGetAutodialEnableW= RasGetAutodialParamW= RasSetAutodialAddressW= [;RASDLG.dll] --- see Lz32 --- RasDialDlgW= RasPhonebookDlgW= (Note how easy that was to cut and paste from one .ini to another!) and this addition to the registry: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "RASDLG"="LZ32.DLL" Now back to 2.14.1 -- its plugin-container.exe requires many more new definitions that will probably be more difficult to implement. Its SeaMonkey.exe does not require the 1.9.1 additions, however, and should work with the new definitions. Try disabling plugin-container.exe (and thus plug-ins) by renaming or deleting it. Finally, if someone could look up those Ras functions above and recommend proper definitions, that would be great!

I've been wondering the same thing for some time now. Perhaps even a VM directly on one of these new super-BIOS'es. Basic hardware would finally become standard; I/O could happen in the background on extra cores; etc. I suggest opening a new Topic because it's only a matter a time before this becomes a major issue!

Thanks to everyone for the testing and feedback. In a slight change of plans, today I'm releasing Iphlpapi4 (Post #1 and Below) and updated Kexstubs.ini definitions (Below). Iphlpapi wrapper Usage with Kexstubs: * Put iphlpapi4.dll in your Windows\KernelEx folder and activate the individual functions in Kstub822.ini: [Iphlpapi.dll] GetAdaptersAddresses=>iphlpapi4: GetPerAdapterInfo=>iphlpapi4: Usage without Kexstubs (or without KernelEx): * Put a copy renamed to iphlpapi.dll in the folder with any app that needs it. * Disable KnownDLLs redirection for Iphlpapi.dll by deleting this key in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI History: Iphlpapi3 implemented GetAdaptersAddresses with information from GetAdapterInfo. Also stubs for GetPerAdapterInfo, GetTcpTable2. Iphlpapi4 implements GetAdaptersAddresses with information from GetIfTable. This adds the Loopback interface to the results as well as real MTU, OperStatus, and link speeds. But lost is DhcpEnabled status (and potentially Gateway and DNS details that I hadn't implemented yet). Stubs for CancelIPChangeNotify, EnableRouter, FlushIpNetTable, GetBestInterfaceEx, GetExtendedTcpTable, GetExtendedUdpTable, GetIpStatisticsEx, GetPerAdapterInfo, GetTcpStatisticsEx, GetTcpTable2, GetUdpStatisticsEx, UnenableRouter. Iphlpapi5 is to be the best of 3+4 and more. But I've been finding lots of errors in MS and third-party documentation and sample code, so I need empirical data to clarify how things should actually work. I will be converting a number of console test apps (based on MSDN samples) into one Win32 app that can be run on any 32-bit Windows platform. Results from dual-boot and VM systems should provide the needed clarity! Updated Kexstubs.ini (Kstub822.ini): Kstub_KnownDLLs.reg REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "CREDUI"="LZ32.DLL" "DBGHELP"="LZ32.DLL" "DNSAPI"="LZ32.DLL" "WINHTTP"="LZ32.DLL" Edit: removed ActCtx / Active Context and Msvcr* definitions Edit2: struck Kex from stubs.ini

>> The System directory is the one place it cannot go! > ...this time I renamed your DLL as IPHLPAPI.JMP and placed it in the System directory, then added the following registry entry... Well, yes, this advanced method is the exception, but it's a global solution that affects the OS and all apps! Test versions cannot override it either by local installation (requires clearing the KnownDLLs entry) or by KernelEx/Kstubs. I recommend using the iphlpapi3.dll name for easier upgrading when the time comes. > Now HoverIP and SAPGUI work just fine! Good, hopefully Opera now does too. > Hmmm ... I've noticed you mention using Bubble Sort a couple of times previously, AFAIK, it's the world's slowest sorting algorithm. Actually, it's the fastest in practice (and nearly in theory) when the dataset is very small or presorted (or nearly so). The slowest in practice is a pure quicksort on reverse-sorted (worst-case scenario) data! Standard quicksorts shuffle (or bit-reversed-index) the data first to vastly decrease the likelyhood of a worst case scenario at the cost of slower average performance. The simple methods have low overhead but don't scale well; the more complex the algorithm, the larger the dataset must be before it become faster. Hybrid implementions often bubblesort small datasets and do a brief analysis on larger sets before selecting what will hopefully be the fastest method. > I've had dramatic improvement in another project where I converted a Bubble Sort into a Shell Sort, only slightly more complicated - I highly recommend it (I ported the example from Peter Grogono's book 'Programming in Pascal'). Ktree processes presorted lists of api names from get_api_table() calls and raw DLL export tables. For the "All API's by name" list, I can do an insertion sort as I process, or load all lists then do a merge sort.

> Thanks Jumper. And Thanks to you, MiKl. There have been 26 downloads of v3, but only you and jds have reported your finding. > I have tried the kstub822.ini method but I am not sure if it had any effect on my system. "No" effect is the best effect when it is not needed! > SeaMonkey 2.0.14 does now start and works perfectly Good. This is back to the "no" effect when not needed. >... but SeaMonkey 2.14.1 still crashes 'blaming' msvcr100.dll. If this means missing exports, you need to update to the latest msvcr100.dll package. > To avoid misunderstandings - I just c&p the four lines from post #101 into kstub822 (I did put them between credui and kernel32) and re-start, correct ? Yes, but that was so "2012". The "2013" method (see updated post #101) is to rename it iphlpapi3.dll and edit Kstub822.ini to match. The change is immediate--no reboot needed! >When you have the time could you test SeaMonkey 2.14.1 on your system ? I can't risk my FF2 setup, but I'll download SM and check it out.

> I copied to the System directory... My IPHLPAPI.DLL is a wrapper, not a replacement. The System directory is the one place it cannot go! > ...and commented out all the IpHlpApi section in "stub822.ini". This isn't necessary unless you use the "content= iphlpapi, Kstub822" method (currently suspect, testing requested!). > PS. A small request for ktree9 : If it isn't too much trouble, would it be possible to sort the DLL names listed under, eg. 'kexbasen'? Like in this Nov 4 test build? Ktree9h.7z Pardon the 10-second hourglass--that's the slow built-in sorting taking place that I've been wanting to correct before release. All the apis in each dll are already sorted, so I just need to do a custom merge-sort in most cases. Three later builds correcting various minor issues also exist, but aren't as usable.

I checked the SeaMonkey 2.6.1 package and didn't find any iphlpapi dependencies or even raw text references. I looked at the SeaMonkey sources and the only reference to iphlpapi is in nsNotifyAddrListener.cpp, the same version as used by FF2..20 and the 1.9.1 core, and the one I have already been using for reference. Apparently that file isn't linked into the 2.x builds of SeaMonkey. So, any problem should also show up in FF2..20. But I've been running with no problems for the last week using the Core.ini method: contents=std,iphlpapi,Kstub822,kexbases,kexbasen You can try using the Kstub822.ini method and only add definitions for GetAdaptersAddresses and GetPerAdapterInfo as needed for other apps: [Iphlpapi.dll] ;any or all of the following: GetAdaptersAddresses=>iphlpapi: GetPerAdapterInfo=>iphlpapi: Iphlpapi.dll can also be renamed for testing in methods other than the local-app-directory method.

In the top-right corner of your diagram, is the active speaker connected to the speaker jack on the PCI card or to the line-out jack?

CPU or memory may be overheating. Try underclocking both, cleaning all heatsinks, and wiping dust from all chips. Next time the problem occurs, be prepared to run thorough cpu and memory test programs immediately after rebooting.

What Iphlpapi dependencies does Dependency Walker list for SeaMonkey? GetAdaptersAddresses was written with Firefox in mind--I studied the 1.9.1 source code (nsNotifyAddrListener.cpp) and looked at the latest as well. And what method did you use? Try using Kstub822.ini to add the functions one-by-one. Note: Kexstubs definitions will override the local copy method. (In case you already have definitions from previous tests.)

Merry Christmas! Version 3 of the Iphlpapi wrapper (2.55K) is now available with near XP-level support for GetAdaptersAddresses and partial support for GetPerAdapterInfo. (There is also a stub for GetTcpTable2.) To use with KernelEx, copy to iphlpapi3.dll in your Windows\KernelEx folder and activate in one of these ways: [*] add individual function(s) to Kstub822.ini: [Iphlpapi.dll] ;any or all of the following: GetAdaptersAddresses=>iphlpapi3: GetPerAdapterInfo=>iphlpapi3: GetTcpTable2=>iphlpapi3: To use without (or with) KernelEx: place (a copy of) iphlpapi.dll in the folder with any app that needs it. Disable KnownDLLs redirection for Iphlpapi.dll by deleting this key in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI Edit: First method not working yet; Last method most tested and working both with and without KernelEx. Edit2: Needs to be named iphlpapi3.dll in KernelEx folder. Edit3: Second method not working yet. Non-working methods hidden in Spoiler.

Good. Before reflashing the BIOS, you can try resetting it (with a jumper or by removing the battery) and then reloading the BIOS defaults. If you previously added the CD drive to the same cable as the HDD, the HDD may not have been jumpered correctly to allow the controller to see the second drive. If you previously attached the CD drive with a separate cable to the secondary controller connector, you can try putting it on the same cable as the HDD. The first goal would be to get both drives to be detected and show up in the BIOS setup. Then when you are booting to DOS, they should also both show up in the hardware summary screen just before DOS begins to load. Did any of the CD drives ever get detected and show up in the BIOS setup or in the boot summary?