jumper

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?

Wash the card then test in another system. Do not connect cables for front panel module! If problem persists at line-level output jacks on card, diagnose the analog channels on the card as follows: monitor the audio signals with a monophonic, (battery-) powered speaker with two probes for inputs. play a monophonic sound that clearly distorts when you think it shouldn't if it sounds the same at both channel jacks, it's not a one-channel problem (i.e. bad cap. in one amp) probe the circuit, tracing the audio signal from the line-level outputs back to the DAC (digital-analog converter) if audio clears up during the trace, identify the faulty component. if the audio is already distorted coming out of the DAC, the card is unfixable.

I think tomasz86 is right: Version 5.1 would be Windows XP. The other two strings seem to be symbols rather than function names.

Your CD drives may be just fine--it sounds like the controller is disabled in the BIOS or you have a bad cable. Now (before you install a new system) is a very good time to revisit your BIOS settings and check all the hardware cabling. In BIOS, make sure both IDE controllers are enabled and then have them autodetect the attached drives. I recommend putting the HDD and CDR on different controllers (different cables) both jumped as Master. Use new cables if you have any. If you only have one good cable, you can put both drives on the same cable. Put the HDD (jumped as Master) on the end connector and the CDR (Slave) in the middle. You will be much happier with this system once you get it running if it has a working CD drive!

@SearanoX: Use Find to search for the text "LdrLoadLock" in files of type *.dll and *.exe in your Windows folder and below. Expand the search as necessary until you find something--It has to be there somewhere! Once you get some hits, use Dependency Walker to confirm. Edit: Just did a Google search and found out there is no such thing as "LdrLoadLock"--did you mean "LoaderLock", "LdrLockLoaderLock", or perhaps "LdrpLoaderLock" ???

An HRESULT is a long int. Using t/-1 is a convenient way of setting the "error" (most sig.) bit. Perhaps SAPGUI treats >0 as recoverable errors and <0 as fatal errors? I was able to add a 6-byte stub (jump to address in jump-table) for each API in my wrapper, so it now can be imported in the standard way. The extra jump table is trivial to create in the loader, and still allows this wrapper implementation to access the original sysdir DLL without needing any file renaming/duplication, etc. iphlpapi.zip GetAdaptersAddresses returns ERROR_NOT_SUPPORTED. GetPerAdapterInfo attempts to function, but probably just returns SUCCESS and an empty list. (see below) GetTcpTable2 returns ERROR_NOT_SUPPORTED. I've been studying the Wine 2003 and 2006 sources for iphlpapi as well as the ReactOS fork (off Wine 2003). With the help of some Wine header files plus a winetypes.h of my own creation, I've been able to extend my VC++5 build environment to handle the Winsock2 and IP Helper API's. I couldn't find an iphlpapi.lib to link with, so I created my own. I've built the MSDN examples for the following seven iphlpapi.dll functions: GetAdaptersAddresses GetAdaptersInfo GetIpAddrTable GetIpForwardTable GetTcpStatistics GetTcpTable GetTcpTable2 Yesterday I searched Google for "getadaptersaddresses sample output" and found a webpage that has the same MSDN GetAdaptersAddresses example along with the (XP?) output. Unfortunately, this site doesn't contain any GetPerAdapterInfo info. I already have a partial implementation for GetPerAdapterInfo, but the Wine/ReactOS sources call upon their own system internals that I had to stub. As a result there is no meaningful data returned yet.... But now I can get to crafting a GetAdaptersAddresses replacement.

> A function of the Win32 API failed This could be a general failure message, or it could mean that HoverIP v1.0 is import-table-linked to iphlpapi.dll. > Error No -2147467263 > 'E_NOTIMPL: Not implemented' SAPGUI is definitely delay-loading iphlpapi.dll via LoadLibrary / GetProcAddress. Let me explain.... The technique of rewriting the DLL export tables at load time works great when the DLL is delay loaded: LoadLibrary loads the DLL into memory and activates the export-table rewriting code; then GetProcAddress reads from the rewritten export table. The normal loader merges these steps and accesses the DLL's export table before executing the entry function. Why? Because it's still checking dependencies and hasn't decided yet whether to execute the parent app! What this means: This technique can be used to implement two different functions with the same name based upon how the DLL is linked or loaded by an app! ...It also means it won't work for our purposes at this time. Stay tuned for the exciting backup plan.

This step should also be preceded by backing up the registry (so it can be restore later if things get worse rather than better) and the BIOS reset to defaults per RJARRRPCGP's post (first writing down the current settings per buyerninety's post). Then to state it more clearly: + if detection problems for other devices persist, cold boot into Safe Mode and remove ALL hardware drivers (especially for the mainboard!) Followed by a cold system restart / normal boot with hardware autodetect. Control Panel->Add new hardware can be invoked if anything doesn't autodetect.

>ISA Sound card stopped functioning (no sound) - device manager suggested a problem - reinstall driver. Some possible causes (and actions to take) for this root problem: CMOS battery died / BIOS IRQ settings changed + Voltage should be at least 2v else replace battery; reset BIOS; set IRQs as needed Registry / drivers corrupted + scandisk HDD to ensure it's not a wider issue + In DOS, "Regedit /restore" last saved registry prior to failure + "Regedit /fix" current registry only if no viable backup Sound card died + shutdown and pull the card + if detection problems for other devices persist, remove ALL hardware (especially mainboard!) drivers in Safe mode + optionally: reinstall sound card once everything else is working and backed-up (if you dare) Mainboard failure: dust in other sockets fried ISA bus; something got zapped; etc. + short term: clean thoroughly; you might be able to run with reduced functionality + long term: replace mainboard I strongly suspect a battery failure, BIOS change, or addition/removal of cards that would change IRQ settings. Most devices are plug-and-play and Windows would adjust, but non-PNP devices such as ISA cards would need redetection. If you did anything in the BIOS or anything inside or outside the case (plugging in or out cards or cables) prior to the sound card failure, please report.

>Would this problem be because of the method I used to update given that I use the latest KernelEx ? Absolutely! But depending on the error, other methods might also produce similiar results. The 12.11 installer may still be on your HDD; it not, download it manually from the Opera site and exit Opera. * Close all other apps and run the installer from Explorer. + You may need to try various KernelEx modes. + You may also need Kexstubs. + You may need to try a portable version of Opera. * You do need to report the text of any error messages so we can figure out how to prevent or avoid them.

Disable KernelEx for the emulator and the plugin. If the problem persists, we'll need to know more about the error. Report all error text including in Details>> or a log file. If none is available, try running the emulator within a light-weight debugger such as Finesse29 to trap the error message.

If your HDD has a large on-board cache, or it is older and slower, then when you shutdown Windows the system may be powering down before the registry is fully flushed (written) from the HDD cache back to the platters. You can try using Regedit to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\CacheWriteDelay to 2000 (decimal) or 4000 if already present. Delay is in milliseconds.

>I wish now that I'd not suggested the 50 return code for GetAdaptersAddresses before checking what was documented. Sure, it works fine for SAPGUI, but perhaps the 232 return code would be more appropriate for other applications (and it works fine too for SAPGUI). // // MessageId: ERROR_NO_DATA // // MessageText: // // The pipe is being closed. // #define ERROR_NO_DATA 232L A pipe error probably won't work universally, either. If you have a solution for your apps, don't worry about others--this is just temporary anyway. I'm working on a real implementation derived from the Wine sources. >I notice that all but three functions in this DLL have the same entry point. Given that different functions will have different stack fix-up requirements, I presume that these other functions don't actually do this (properly). So, if any of these other functions are called (eg. HoverIP uses a bunch of functions from IpHlpApi), this DLL would be unsafe. Is that correct? No! You may also have noticed that it doesn't require that the original DLL be copied to another name. It also doesn't require KnownDLL tricks (another way to access the system DLL of the same name). What it does is rewrite its export table at load time to redirect the standard functions to the originals in sysdir. In addition to the stubs (currently) for GetAdaptersAddresses and GetPerAdapterInfo, it also exports a KernelEx-compatible get_api_table. This make it a hybrid Kext DLL that can also be used by KernelEx non-users. I now have a partial implementation of GetPerAdapterInfo working and hope to release it soon. The test plan is to build the MSDN sample code for each API and run it on various platforms, with and without my extension DLL, comparing results.

iphlpapi.zip Unzip iphlpapi.dll into app folder remove HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs\IPHLPAPI entry remove definitions for GetAdaptersAddresses and/or GetPerAdapterInfo from Kexstubs.ini stubs returning E_NOTIMP (0x80004001) for GetAdaptersAddresses and GetPerAdapterInfo will be added to IPHLPAPI in sysdir for just this app. Edit: struck Kex from stubs.ini

I've been having trouble with core.ini processing, also. It doesn't always work they way it appears it should. Even cloning existing profiles isn't reliable. One thing I learned about core.ini mods several months ago is that a full system reboot is necessary between every change--restarting Windows isn't enough. Naturally this greatly slows down the trial-and-error testing! I looked in the source code at how the property sheet changes the mode and think I can write a utility to test each and all profiles to see which will stick if selected after modification (and reboot). Kex changes the mode to default if it doesn't like something about the selected mode. It's been a few months since I looked at the source code for the Core.ini loader. Until I do that again, instead of using a new profile we'll have to stick to modifying the Kexstubs.ini definition on-demand: GetAdaptersAddresses can be changed between r50s5 and t5 immediately before launching an app that needs the other definition. Edit: struck Kex from stubs.ini

>...no way for me to press apply. Press Alt+A to Apply.

A bit of research indicates SUSE has the best change of including X-Fi drivers on the LiveCD. Otherwise, you need to get them from a linux repository and install to a flashdrive (or something.... )

You can also try testing with a different OS. Assuming you don't dual-boot, a Linux live-CD should do....

On the Options tab, check the third box: "Show file version information (slower)"

DISKdata

>Hmmm ... So the only setting so far that is compatible between µTorrent and SAP GUI for Java 7.10r3 is no setting. Too bad the latest Opera doesn't agree with that. For Opera and any other apps that won't load without GetAdaptersAddresses, we'll create two definitions in Kexstubs.ini: [IPHLPAPI.DLL] GetAdaptersAddresses=r50s5 ;.0 GetAdaptersAddresses=t5 ;.1 Then we'll disable them by default in Core.ini: [DCFG1.names.98] IPHLPAPI.GetAdaptersAddresses=none [DCFG1.names.Me] IPHLPAPI.GetAdaptersAddresses=none Then add new profiles in Core.ini to support them: [ApiConfigurations] default=0 0=DCFG1 ... 11=W2KGAA0 12=W2KGAA1 [W2KGAA0] inherit=NT2K desc=Win2K+GetAdaptersAddresses.r50s5 [W2KGAA0.names] IPHLPAPI.GetAdaptersAddresses=Kexstubs.0 [W2KGAA1] inherit=NT2K desc=Win2K+GetAdaptersAddresses.t5 [W2KGAA1.names] IPHLPAPI.GetAdaptersAddresses=Kexstubs.1 As needed: Replace "Kexstubs" with "Kstub822" These new profiles can inherit from any other profile Edit: struck Kex from stubs.ini

It looks like Phaenius is just playing a CD in this test. He should also try the same CD in Windows CD Player as an alternate audio source and compare results.

To the right of the top-left-most arrow is the WinAmp Mute button and then a Volume slider. You have the slider set very low. To get more volume, slide it all the way to the right and Pump Up the Volume! Then turn down the volume at the speakers until it doesn't distort. B) In the picture, the VU meter pointed to by the arrow show no color and appears to also be indicating low playback volume being sent to the system mixer. Press Alt+G to check WinAmp's internal equalizer and preamp levels. >Another thing is the Windows 7 mixer (which I don't get it). I attached a picture. Are you saying that clicking on the Mixer button at the botton of the System Volume control does nothing? Try double-clicking on the Volume control in the systray to open the mixer. Once you find the system mixer, report the levels found there. Make sure you select all volume controls in Options->Properties. You should also explore the Audio tab of the Multimedia Control Panel, especially Playback: Advanced Settings->Performance.