[schwups]

schwups, on 05 October 2012 - 04:02 AM, said:

With "[IPHLPAPI.DLL]GetAdaptersAddresses=r120s5" in the ini file µTorrent 2.0 crashes on start. 

µTorrent doesn't crash with  "GetAdaptersAddresses=t5"

[jds]

[IpHlpApi.dll]
GetPerAdapterInfo=r50s3e50 ; Error_Not_Supported, 3 Params

Enables HoverIP v1.0b to work with "iphlpapi.dll" version 5.0.1717.2 (newer versions I've found, such as 5.0.2173.2, have the required function but unfortunately also a whole bunch of dependencies).

Joe.

[jumper]

According to MSDN, GetPerAdapterInfo doesn't set the last error via SetLastError(). So without the "e50" that should be:

[IpHlpApi.dll]
GetPerAdapterInfo=r50s3 ; Error_Not_Supported, 3 Params

[jds]

jumper, on 16 November 2012 - 04:17 AM, said:

According to MSDN, GetPerAdapterInfo doesn't set the last error via SetLastError(). So without the "e50" that should be:

[IpHlpApi.dll]
GetPerAdapterInfo=r50s3 ; Error_Not_Supported, 3 Params

Thanks, jumper. I've confirmed that HoverIP works just fine without the SetLastError option.

Looking at the MSDN information, I suppose if it doesn't mention anything about a function setting the "last error" code, it means it isn't set.

Joe.

This post has been edited by jds: 19 November 2012 - 01:01 AM

[jds]

schwups, on 14 November 2012 - 02:31 AM, said:

schwups, on 05 October 2012 - 04:02 AM, said:

With "[IPHLPAPI.DLL]GetAdaptersAddresses=r120s5" in the ini file µTorrent 2.0 crashes on start. 

µTorrent doesn't crash with  "GetAdaptersAddresses=t5"

I've just tried this 't5' setting and it produces this problem with SAP GUI for Java 7.10r3 when connecting to the server :

Quote

Error: internal error
Mon Nov 26 17:06:05 2012
Release 710
Component NI (network interface), version 39
rc = -1, module ninti.c, line 214
Detail NiPGetNodeAddrList03
System Call GetAdaptersAddresses
Error No -1

However, the following (undocumented return code for this function?) works OK for SAP GUI (no Kstub entry also works) :

Quote

GetAdaptersAddresses=r50s5

Joe.

[schwups]

[IPHLPAPI.DLL]
GetAdaptersAddresses=t5  works for µTorrent 2.0. => Kstub822.log: " = IPHLPAPI.DLL:GetAdaptersAddresses=t5 ="


GetAdaptersAddresses=r50s5 or r120s5 doesn't work for it. => Kstub822.log: "= IPHLPAPI.DLL:GetAdaptersAddresses=r50s5 =" or "= IPHLPAPI.DLL:GetAdaptersAddresses=r120s5 ="

[jds]

schwups, on 27 November 2012 - 10:55 AM, said:

[IPHLPAPI.DLL]
GetAdaptersAddresses=t5  works for µTorrent 2.0. => Kstub822.log: " = IPHLPAPI.DLL:GetAdaptersAddresses=t5 ="


GetAdaptersAddresses=r50s5 or r120s5 doesn't work for it. => Kstub822.log: "= IPHLPAPI.DLL:GetAdaptersAddresses=r50s5 =" or "= IPHLPAPI.DLL:GetAdaptersAddresses=r120s5 ="

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 completeness, these are the documented return codes that SAP GUI for Java likes : 8, 87, 111, 232, 1228. It also likes undocumented return codes : 1, 50, 120. It doesn't like -1 and I don't dare try 0 (too risky).

Joe.

[jumper]

>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

This post has been edited by jumper: 04 February 2013 - 03:57 PM

[jds]

jumper, on 28 November 2012 - 10:13 PM, said:

>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

Well, SAPGUI is happy with GetAdaptersAddresses disabled, so perhaps only the 't5' setting is required, for Opera.

Also, it would be good to know if another setting such as 'r232s5' may work with µTorrent or even Opera. The return code 50 was one that I'd copied from another IpHlpApi function (GetPerAdapterInfo) for HoverIP, and isn't actually documented for GetAdaptersAddresses. SAPGUI accepted it and indeed, seems to except many other return codes, but not -1.

Joe.

This post has been edited by jds: 06 December 2012 - 02:09 AM

[schwups]

jumper, on 28 November 2012 - 10:13 PM, said:

>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

My first try failed.


I couldn't start Opera  12.5 builds 1513 and higher, except build 1578 (12.02). Message: "Opera Error - Failed to load Opera.dll because: A device attached to the system is not functioning." The setting W2k+t5 wasn't kept. The comp mode window changed to default mode. I'll try it again.  

This post has been edited by schwups: 29 November 2012 - 07:58 AM

[Giant2011]

opera 12.50.1497 starts on my computer the plugin wrapper gives a problem though. I have windows 98 SE and kernelex 4.5.2

[jumper]

schwups, on 29 November 2012 - 04:39 AM, said:

My first try failed.

I couldn't start Opera 12.5 builds 1513 and higher, except build 1578 (12.02). Message: "Opera Error - Failed to load Opera.dll because: A device attached to the system is not functioning." The setting W2k+t5 wasn't kept. The comp mode window changed to default mode. I'll try it again.

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

This post has been edited by jumper: 04 February 2013 - 03:58 PM

[jumper]

 iphlpapi.zip (1.59K)
Number of downloads: 11

• 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

This post has been edited by jumper: 04 February 2013 - 03:56 PM

[jds]

jumper, on 03 December 2012 - 12:16 AM, said:

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.

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).

jumper, on 04 December 2012 - 06:41 PM, said:

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.

Hi jumper,

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?

Joe.

[jumper]

>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.

[jds]

jumper, on 06 December 2012 - 06:36 AM, said:

What it does is rewrite its export table at load time to redirect the standard functions to the originals in sysdir.

Neat! Thanks for the clarification, jumper.

Joe.

[jds]

jumper, on 04 December 2012 - 06:41 PM, said:

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.

Hi jumper,

FYI, here are the results of testing the 2012/12/04 edition :

HoverIP produces the following error message, then seems to work normally :

Quote

HoverIP v1.0

Une fonction de l'API Win32 a échoué.

SAPGUI produces the following error when trying to connect to the server, doesn't work :

Quote

Connection failed

Error: internal error
Tue Dec 11 14:26:27 2012
Release 710
Component NI (network interface), version 39
rc = -1, module ninti.c, line 214
Detail NiPGetNodeAddrList03
System Call GetAdaptersAddresses
Error No -2147467263
'E_NOTIMPL: Not implemented'

Joe.

[jumper]

> 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.

[jds]

jumper, on 13 December 2012 - 05:38 PM, said:

> Error No -2147467263
> 'E_NOTIMPL: Not implemented'

SAPGUI is definitely delay-loading iphlpapi.dll via LoadLibrary / GetProcAddress.

Agreed. Also, evidence to date is that SAPGUI doesn't accept any negative return values for this function.

Joe.

[jumper]

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 (2.2K)
Number of downloads: 4

• 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.