[jumper]

Drugwash, on 23 March 2012 - 07:41 PM, said:

I mocked up a simple tool that returns the number of parameters for an API name given as command-line parameter...Hopefully it may be of help to someone....

Thanks, Drugwash. Good work. I rate it two thumbs up:

I see the update now alphabetizes and can also sort by parameter count. Also ~450 duplicates have been removed from the list!

I've added a link to your post (#80) in the header of post #1, and also a mention in the topic subtitle.

[Drugwash]

You're welcome! It wasn't much of a challenge, anyway; currently I'm working on parsing the headers in PSDK2003 and building a constant database for use in AHK. Found over 67850 so far, but the parsing code is still buggy. I'd be glad to find someone with a more recent PSDK installed (ideally one that includes Vista/7 or even 8's headers), to pass them the parsing script and retrieve an updated list of constants. When I fix it, that is.
I haven't yet looked at your code, but I can't stop asking myself how would it know what are the allowed return values & value types for each API function it patches... unless I misunderstood its usage.

If you need any other tool, don't hesitate to ask - I'll try to rise up to the challenge the best I can.

[jumper]

Drugwash, on 27 March 2012 - 07:51 PM, said:

I haven't yet looked at your code, but I can't stop asking myself how would it know what are the allowed return values & value types for each API function it patches... unless I misunderstood its usage.

ImportPatcher lets us replace any DLL or function name string with any other string that will fit. It then checks to see if those DLLs and functions exist, but doesn't do any return value or type checking--that is up to the user to research (or guess!) which stub is the best to use.

Matching the number of parameters is important for preventing stack corruption. Return value is important because it can signify success or failure; the actual type doesn't matter if the raw value is correct.

Ideally, the user would research each function to be replaced at MSDN before selecting (or writing) a stub with the best characteristics. I think guestimation and trial-and-error are the methods that often get used instead.

[Drugwash]

Oh well, I had a funny feeling I won't be taking care of the garden this year either... Since it's closely related to my own needs, I may be taking on the task of building an as-updated-as-possible API database, complete with library location, parameter count & type and - most important - return value & type. As a mini-MSDN.
The return value is indeed very important, not only in terms of success/failure indication, but in certain situation may have to represent a pointer to a string or worse: a pointer to a pointer.
Things get complicated when the original API would return a pointer to a POINT, RECT, COLORREF or more complex structure. But that's already too much to dig for - we may as well build the API replacements from scratch, as is the case with KernelEx.

[jds]

jds, on 09 March 2012 - 01:56 AM, said:

jumper, on 08 March 2012 - 03:04 PM, said:

Great job getting Altium Designer Viewer to install and launch.

Yeah, so close and yet ...

I get the impression that NT has more internal traps for errors that are silently dealt with than does W9X. So coding errors (hey, even compiler errors!) go unnoticed. Maybe that's it, or maybe there are a few holes or bugs in what KernelEx is providing, I don't really know.

Well, I have progress to report, of sorts.

In investigating this error, I encountered some test results at WineHQ with different versions of Altium Viewer (albeit with different versions of Wine). This suggested that versions up to 6.8 were well behaved, whereas the more recent versions, weren't. So I did a search of some backups and found a copy of version 6.3.0.6886 and installed this, as described earlier (the MSI LaunchCondition was a bit different, but fairly obvious).

It works! However there's a catch. Previous versions of Altium Viewer require a registration key and activation. Unfortunately, the system Altium have for generating such registration keys no longer works for version 6, so I had to get help from Altium Support to get a suitable registration key generated. Then it all worked!

Unfortunately, Viewer 6 is no longer supported by Altium, so unless you're a good customer, they won't normally be willing to manually generate a registration key for it. However, this does show that Altium Viewer is viable on W98, version 6.3 works, and more recent versions perhaps just require one or two API functions to be fixed up for them to work too.

jumper, on 28 March 2012 - 01:40 AM, said:

Ideally, the user would research each function to be replaced at MSDN before selecting (or writing) a stub with the best characteristics. I think guestimation and trial-and-error are the methods that often get used instead.

I can't agree more. I did such research before selecting the two IPStub functions to use with Altium Viewer, there's enough that can go wrong to trust trial and error.

Joe.

This post has been edited by jds: 30 March 2012 - 08:20 AM

[jds]

Installing "SAP GUI for Java (Win32) 7.10r5" on W98/KernelEx :

Here is a very brief description of the special steps needed to install "SAP GUI for Java (Win32) 7.10r5" on W98/KernelEx, with the help of "Import Patcher" and 'IPStub.dll' ...

0) Prerequisites

Well, these are the official prerequisites :

Quote

Hardware
CPU: Intel PentiumIII with 800 MHz
RAM: 512 MB (Vista 1 GB)
Software
Windows XP 32bit or Windows Vista 32bit (Business, Ultimate und Enterprise Edition)
Visual C++ Libraries VS 2005 SP1(x86)
This package (VCredist_x86.msi) is available in the bin directory of the SAP GUI for Java installation or at the same locations where the installers of SAP GUI for Java are located for download.
Sun Java Runtime Environment 5.0 (32-bit) from http://java.sun.com/...1.5.0/index.jsp or 6.0 (32-bit) from http://java.sun.com/javase/6/

The other prerequisite is a copy of the "SAP GUI for Java" (Win32 version) installation package, once readily available via FTP from SAP, now you need to register and navigate their convoluted web site to get it. The version used here was 'PlatinGUI-Win32-710r5.jar', however, only the most current version is generally available from SAP, which may or may not work as below. Note that version 7.10 is the minimum required to access current SAP systems.

1) Create directory structures on your W98 partition

C:\Users
C:\Users\YourUserName
C:\Users\YourUserName\Local
C:\Users\YourUserName\Local\Temp
C:\Users\YourUserName\Roaming
C:\WINDOWS\SAP Clients
C:\WINDOWS\SAPGUI
C:\WINDOWS\SAPGUI\work

2) Add "Volatile-Environment" Registry Entries

---snip---
REGEDIT4

[HKEY_CURRENT_USER\Volatile Environment]
"LOGONSERVER"="\\\\SERVERNAME"
"USERDNSDOMAIN"="Your.Domain.Suffix"
"USERDOMAIN"="YOURDOMAIN"
"USERNAME"="YourUserName"
"USERPROFILE"="C:\\Users\\YourUserName"
"HOMEPATH"="\\Users\\YourUserName"
"HOMEDRIVE"="C:"
"APPDATA"="C:\\Users\\YourUserName\\AppData\\Roaming"
"LOCALAPPDATA"="C:\\Users\\YourUserName\\AppData\\Local"
---snip---

3) Obtain REG.EXE

Extract with 7-Zip from 'sp4supporttools.exe' from :
http://www.microsoft...n.aspx?id=18614

Copy to %windir%

4) Obtain CMD.EXE

WIN95CMD.EXE (originally from October 2000 Platform SDK) :
http://web.archive.o...ze/Win95Cmd.exe

Possible alternative is CMD.EXE from ReactOS 0.3.1 or earlier.

Copy to %windir%

5) Pipe Work-around for WIN95CMD.EXE (Charles Dye)

---snip---
REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor]
"AutoRun"="set comspec=C:\\windows\\cmd.exe"
"CompletionChar"=dword:00000009
---snip---

6) Update in %windir%\SYSTEM :

IMAGEHLP.DLL 5.1.2600.2180 (Readily available)
dbghelp.dll 6.0.0017.0 (Available in 'WinAVR' or 'RealPlayer')

7) Install the JAR package

8) Patch 'JPlatin.dll' with "Import Patcher" & 'IPStub.dll'

---snip---
[ImportPatcher.34]
;Edit parameters and replacement strings, then Retry or run again to patch. <=

[Parameters]
Walk dependencies=N
Link to copies=N
Unbind broken bindings=N
Target OS=4.10

[DLL substitutions]
Netapi32.dll=IPStub.dll

[KERNEL32.dll]
OpenThread=

[ADVAPI32.dll]
ConvertStringSecurityDescriptorToSecurityDescriptorA=

[IPStub.dll]
NetUserEnum=o8
Netbios=f1

[Patch list]
JPlatin.dll=DLLs, Functions
---snip---

9) Here's the batch file to invoke SAP GUI :

---snip---
javaw.exe -Xmx256M -cp "C:\PROGRA~1\SAP Clients\SAPGUI for Java 7.10rev5\jar\GuiStartS.jar";"C:\PROGRA~1\SAP Clients\SAPGUI for Java 7.10rev5\jar\platincoreS.jar" %PLATIN_JVMOPT% com.sap.platin.Gui %1 %2 %3 %4 %5 %6 %7 %8 %9
---snip---

Phew! Well, that's pretty much it!

Joe.

This post has been edited by jds: 16 April 2012 - 10:49 PM

[jumper]

Here's a new stub file designed just for NetApi32.dll issues:

NetApiEx.dll -  NetApiEx.zip (827bytes)
Number of downloads: 17

Contains stubs for all missing NetApi32 functions reported anywhere on the web:

NetApiBufferFree
NetFileGetInfo
NetGetDCName
NetLocalGroupAddMembers
NetServerEnum
NetShareGetInfo
NetUseAdd
NetUseGetInfo
NetUserDel
NetUserEnum
NetUserGetInfo
NetUserGetLocalGroups
NetWkstaGetInfo

All stubs support the proper number of parameters and return ERROR_INVALID_FUNCTION (1).

Four ways to use NetApiEx.dll:

• Place in app or %system% folder and use ImportPatcher to redirect app to it. (for testing mainly)
  
• Rename to NetApi32.dll and place in app folder. (local usage; must not be listed in KnownDLLs)
  
• Rename to NetApi32.dll and place in %system% folder after renaming original to NetApi00.dll
  
• Place in %KernelEx%, add to 'contents' list in Core.ini, and use as a new KernelEx extension:
  contents=std,kexbases,kexbasen,NetApiEx

Yes, you read that right -- NetApiEx contains a KernelEx api_table structure and exports a "get_api_table" function so KernelEx can use it in the same way as kexbasen and kexbases.

In fact, NetApiEx is a hybrid. Unlike kexbasen and kexbases which only export get_api_table, it also exports the API functions. This allows it to work without KernelEx ala methods one, two, and three.

NetApiEx can be used (in conjunction with NetApi00) as a direct replacement for NetApi32 in %system% (method three) because it also contains an export-forwarder for Netbios, the one native API. Method three will work both with and without KernelEx.

Because Net* functions other than Netbios are NT functions, it is very likely that any app needing NetApiEx will also need KernelEx to handle other issues. Hence the appeal of method four.

[loblo]

Hi jumper, the netbios forwarder thing doesn't seem to actually work here. If I check with dependency walker, it appears OK but upon trying to start the program it fails with a message saying the blahblah file is linked to missing export NETAPI32.DLL:Netbios.

Also, the NetMessageBufferSend function isn't available in your dll.

I've got that 3DVIA Printscreen program (for capturing 3D models from opengl and directx applications) that's got a dll requiring both NetMessageBufferSend and Netbios from netapi32 and it works absolutely fine with a netapi32 I made myself a while ago and that has both functions as dummies but it fails with yours for the reasons I mentioned above.

This post has been edited by loblo: 18 April 2012 - 09:09 AM

[jumper]

Loblo, you didn't mention which method(s) you tested. I not sure which method is failing or in what mode the dll is having trouble.

Here is an updated file with both NetMessageBufferSend and Netbios stubbed. Since this makes it a superset of your stub file, it should work using the same method (2?). Method 4 is where I could use help testing and some feedback.

Thanks for testing!

Attached File(s)

•  NetApiEx2.zip (848bytes)
  Number of downloads: 11

[loblo]

This one is working OK but it's not so different than mine since netbios is stubbed and not forwarded.

For testing the other one I used a mixture of method 2 and 3 which is to say I did rename your dll to netapi32.dll and did put in the application folder and I also copied to it the original netapi32.dll from the system folder (renamed as NetApi00.dll of course) which theoretically should have been working for the netbios function if I am not mistaken.

Have you succesfully tested a netbios function forwarding and if so can you tell on which program so I can try it out myself?

This post has been edited by loblo: 18 April 2012 - 07:36 PM

[loblo]

Btw, here are some more netapi32 functions you may want to add in your dll:

NetGetAnyDCName
NetGroupEnum
NetGroupGetInfo
NetGroupGetUsers
NetShareEnum
NetUserGetGroups

This post has been edited by loblo: 18 April 2012 - 08:10 PM

[jumper]

> This one is working OK but it's not so different than mine since netbios is stubbed and not forwarded.

Right. It should be identical to yours, but with another dozen stubs as well. I wanted to avoid the forwarding problem for now, but using it globally in %system% could break other apps that need a working Netbios.

> For testing the other one I used a mixture of method 2 and 3 which is to say I did rename your dll to netapi32.dll and did put in the application folder and I also copied to it the original netapi32.dll from the system folder (renamed as NetApi00.dll of course) which theoretically should have been working for the netbios function if I am not mistaken.

Should have worked. More testing needs to be done on this front.

> Have you succesfully tested a netbios function forwarding and if so can you tell on which program so I can try it out myself?

No, I have yet to find a suitable program. The forwarding is produced by the VC5 linker from a .def file the same way that works for the ComDlgEx open and save functions.

...Okay, a brute-force search of my entire 30GB HDD just now found a program named winbox.exe that is static-linked to Netapi32.Netbios. But none linked to the NT Netapi32 functions. I'll do some testing and report back....

[jumper]

NetApiEx is only marginally related to ImportPatcher, so discussion and updates will continue in [ this Netapi32 topic ].

Thanks,

jumper.

[Drugwash]

API Parameter Count v1.0.2.0 is out. Just a few bugfixes and improvements. Enjoy!

DOWNLOAD executable + source code Homepage

[jumper]

When stubbing, in addition to parameter counts, we also need to know calling convention.

If a function uses the Pascal / WINAPI calling convention, the stub must clear the parameters off the stack. If a function uses the "C" calling convention (caller clears parameters off stack), the stub must not.

IPstub.dll has a family of WINAPI stubs. When stubbing for a "C" function, the zero-parameter form should be used.

(The FASTCALL convention usually passes the first two parameters in registers and the rest on the stack, but is not use when dynamic linking.)

[Drugwash]

Is there anything you would want me to add to the tool above? I'm not sure if an automatic parsing of the header files would yield proper results in regard to detecting calling convention and whatnot. I may need more details as my knowledge of C/C++ is pretty shallow.

[jumper]

New in ImportPatcher.37.zip:

• default option to test for API's with LoadLibrary/GetProcAddress if any DLL or API is missing
  
• iterate needed imports even if DLL is missing or has no exports
  
• "Target OS" -> "OS Subsystem Version [Ceiling]"
  
• nicer formatting of TimeDateStamps and ordinals in log

Detects availability of API's provided by KernelEx and DLLHOOK. Set KernelEx compatibility mode to level of desired detection.

For users of Kexstubs, blank definitions for missing functions can be copied directly from the output .ini files into the corresponding section in stubs.ini.

[schwups]

jumper, on 20 September 2012 - 01:36 AM, said:

Set KernelEx compatibility mode to level of desired detection.

I also had tried to change comp. mode of the ImportPatcher.exe to see what happens. It was a bad idea. I had to reinstall KernelEX. So I have to set the comp. mode of the app only.

[jumper]

>I also had tried to change comp. mode of the ImportPatcher.exe to see what happens. It was a bad idea. I had to reinstall KernelEX.

ImportPatcher is just another app in that it doesn't know about KernelEx. It doesn't read from or write to any part of the KernelEx (or Kext) configuration. More details about what exactly you did would be helpful.


>So I have to set the comp. mode of the app only.

IP37 also doesn't read the target app's KernelEx configuration mode, and its analysis is unaffected by how it is currently set.

I recommend making a copy of IP37 and naming it IP37kex; then set the KernelEx mode of IP37kex all the way up to Win2008 and disable it on the original. That way you can easily test with and without KernelEx. (Beware that output files will collide, however, so copy them if you wish to WinDiff them.)

[jds]

Hi jumper,

I tried a little experiment recently to graft the W2K version of 'mpr.dll' into a W98 system, in an attempt to map network drives using domain-based DFS, where a fully qualified domain name (I think that's what it's called) is used instead of a NetBIOS hostname and (as if that wasn't enough) the share is on a subdirectory of the root. I don't know if 'mpr.dll' is the correct target, this was largely based on guesswork.

The plan involved also taking the W2K versions of 'NTDLL.DLL', 'rpcrt4.dll', 'advapi32.dll' and 'kernel32.dll', renamed to 'N2DLL.DLL', 'r2crt4.dll', 'a2vapi32.dll' and 'k2rnel32.dll', respectively. This was in order to satisfy all the dependencies of the W2K version of 'mpr.dll'.

Anyhow, after applying Import Patcher 37 to all these files, to substitute these DLL names, I found that 'k2rnel32.dll' (formerly 'kernel32.dll' of W2K) still had a run-time dependency on 'ntdll.dll' (instead of the renamed 'n2dll.dll'), from a call to "ntdll.RtlDeleteCriticalSection". Looking via a hex editor, I found a number of similar function calls, which I manually edited to suit the renamed (and patched) 'n2dll.dll'.

So it seems that Import Patcher doesn't detect DLLs that are called this way, when you try to do a DLL substitution. Hopefully this can be addressed in a future version of IP, when time permits, of course.

There were also one or two instances within most of these patched DLL files, where the names of DLL files such as 'ntdll.dll' remained unpatched. I don't know the significance of these strings still being present, so I manually edited these too.

BTW, this experiment was a failure. Even with the dependencies of these DLLs apparently addressed, this house of cards just crashes. So I still cannot tell if 'mpr.dll' would have helped with this newfangled drive mapping syntax.

Joe.