I am putting together a library of useful system functions and would like to have it tested. Also opinions, criticisms and suggestions would be greatly appreciated. This is part 4 of my comprehensive lib package (not yet released or finished even) the first 3 are Strings, Conversion and Files. The following is a list of the functions and there usage to date, all have been tested with both GoAsm and MASM. For MASM you must inludelib the lib file and add the protos at the bottom of this post to your code. For GoAsm you just specify the lib path in the invoke statement.


I have moved the lib to my website
Posted on 2004-06-28 13:08:42 by donkey
There is an issue with MASM builds, you must add the switch /FORCE:MULTIPLE to the LINK.EXE command line or projects using the PSAPI or TOOLHELP32 functions in more than one call will fail to build. Still trying to work around the problem in GoAsm. This issue will be fixed up in the final version.

Fixed for now, new upload at top.
Posted on 2004-06-28 14:30:11 by donkey
Nice work donkey :alright:.

You might want to check that e_lfanew is inside the mapped image before you check the bytes at that offset, in case somebody runs it on e.g. a compressed DOS executable.
Posted on 2004-06-28 15:26:02 by Jibz

Nice work donkey :alright:.

You might want to check that e_lfanew is inside the mapped image before you check the bytes at that offset, in case somebody runs it on e.g. a compressed DOS executable.

Thanks Jibz,

Good idea, done and uploaded.
Posted on 2004-06-28 15:56:55 by donkey
Thanks for the wonderfull library, donkey! Keep the good work up!



/siddhartha
Posted on 2004-06-29 18:15:24 by siddhartha
No probs siddhartha,

Mostly it's for me but I thought I would share, not many suggestions for functions though. Hopefully there will be some before I finish the lib.
Posted on 2004-06-30 03:26:58 by donkey
Very nice donkey, just a comment from me that perhaps, for consistency within you library, all your functions should return the same value if the call fails ?

even some constant ?

still, very useful :)
Posted on 2004-06-30 19:50:00 by abc123
perhaps another useful function would be to get
the access rights of the user, and even some things
related to sockets might be interesting.

GetConnectionType (cable, modem, dsl)
IsConnected

and related to winXP (or nt, can't remember if it
supports it), but you could provide interfaces to
get list of logged in users, list of processes based
on user, isUserLoggedIn

... just throwing some ideas out there :)
Posted on 2004-06-30 19:54:02 by abc123
Hi abc123,

I have thought quite a bit about return values and try to make them sensible. For the most part -1 indicates an error condition except where some strings are concerned. Then usually it will give the length of the string or 0 in error. Mostly in the few cases of 0 being error have to do with what function will normally be expected to follow it, for example with path functions you would normally expect a concatentation and therefor the length of the string is useful, -1 in that case would be cumbersome, 0 is a much better return. In the cases where handles are expected or callbacks -1 is returned on error, as you know that is INVALID_HANDLE_VALUE and will not crash Windows if you pass it directly to a handle based function. For other functions the return value means nothing and they simply return true or false. Lastly those that use COM will generally return the COM S_OK for success and -1 otherwise. It may seem like a hodgepodge but the functions are mostly designed to return information I am likely to use, not just OK/NOTOK.

Communications and networking is for another library, though I doubt that it will be me that writes it. It is not something I find particularly interesting and have not studied it much. I will look into the Log-In question and see if it can be done across a wide range of OS versions effectively, I do not want to include too many functions that are for only one OS version, so far there is only one that will not work on every Windows version from NT4 to 2K3 (GetParentPID has no NT4 version).
Posted on 2004-06-30 20:05:41 by donkey
There was a small bug resetting the thread priority back to it's original value in the CPUSpeed routine, it has been corrected and the fix uploaded.
Posted on 2004-06-30 22:38:47 by donkey
I have added two new functions, WaitForProcess that will wait for a process identified by it's PID to terminate before continuing and SingleInstance, that allows only one instance of an application to run. Unlike the MASM32 versions of these commands they use kernel objects rather than silly tricks or loops to do the job and are reliable. The lib has been uploaded to my website. Both have been tested under MASM and GoAsm.

Check out the new string library while you're there, it features faster algos than MASM32 and Unicode versions of most of them. It also has a very simplistic string array set of functions if you just need something for a small number of strings. I am planning a linked list type library for strings in the near future but I saw a need for something simple. I have not tested the string library with MASM and would appreciate feedback on it.
Posted on 2004-07-03 15:10:18 by donkey

(GetParentPID has no NT4 version).

This could probably be implemented via a call to NtQueryInformationProcess - at least it wouldn't surprise me. I could try looking into it if you're interested?

Anyway, from a (very :) ) quick look at your library, it seems robust and pretty well written. Nice to see that somebody does a good job ;)
Posted on 2004-07-03 16:18:47 by f0dder
This could probably be implemented via a call to NtQueryInformationProcess - at least it wouldn't surprise me. I could try looking into it if you're interested?


Hi f0dder,

Thanks, to be honest I didn't really bother checking for NT4 but I have MSDN and will take a look.

Anyway, from a (very ) quick look at your library, it seems robust and pretty well written.


Thanks, I have tried to make it as robust as possible, in cases of critical functions I even check the pointers passed to see if they are probably valid, so even if you pass say 123 for a pointer (which would normally crash most functions that test only NULL) in GetModuleByAddr9x the lib should be able to recover. Ofcourse this was especially critical for the ExceptionMessage function.

Nope, NtQueryInformationProcess - Included in Windows XP and Windows 2000 Professional. Doesn't extract the right info anyway
Posted on 2004-07-03 17:12:03 by donkey

Thanks, to be honest I didn't really bother checking for NT4 but I have MSDN and will take a look.

The call is undocumented, but exists (afaik) since NT4. Or well, it's "semi-documented" now, but the call returns more information than the documentation says it does ;)
Posted on 2004-07-03 17:54:55 by f0dder


The call is undocumented, but exists (afaik) since NT4. Or well, it's "semi-documented" now, but the call returns more information than the documentation says it does ;)


Well, I have no docs on what it returns, if you could check I would appreciate it, I have an NT4 system here to test on.
Posted on 2004-07-03 17:56:48 by donkey
Hi f0dder,

I figured it out ! It is the Reserved3 parameter of the PROCESS_BASIC_INFORMATION structure that holds the parent ID. I will run some tests and include an NT version of the function. I also ran into a problem while testing that led me to include yet another function NTSTATUSToString will convert a kernel mode return to a string. I will add both once I have tested them.
Posted on 2004-07-03 23:28:08 by donkey
Yup, it's one of the "reserved" fields. So it _is_ available under NT4? Nice! Sorry that I didn't get the time to find it for you before you did so yourself, but I had a friend over :)

If you want to go all-out on supporting all windows versions, you could even dynamically choose whether to use toolhelp32 or psapi for various things... but that's probably a bit over the edge ;)
Posted on 2004-07-03 23:47:48 by f0dder
Not sure about NT4 yet, I still have to set up the tests, I just finished coding the function for the lib and have to design a few tests to check it out. But it works flawlessly on 2K. I do allow for 9x or NT for almost all the PSAPI functions, I figure that the person using the library can check the OS version and select the function themselves, I find the ones that check everything for you are a bit heavy. All PSAPI and ToolHelp32 functions are loaded dynamically so the ToolHelp32 version being in the program will not break NT4 code.

Though the GetPIDFromhProcess does break 9x, I put that in the release lib by mistake it is for my version only as I need it sometimes and it is only available as an API from 2K3. It is so esoteric of a function and so particularly targetted at 3 of my apps that I figure nobody will ever use it ;) However it is not a big job to make a 9x version.
Posted on 2004-07-04 00:07:09 by donkey
Yup, tested perfectly with NT4 so the 2 new functions are added and uploaded. Took a bit to make sure that it matched the output of the 9x version. The GetPIDFromhProcess will no longer break 9x applications but I have not written the 9x version yet.
Posted on 2004-07-04 01:28:05 by donkey
Well, it's amazing what one little change will do :) The lib was severely broken due to a typo when I was setting up the calls for the PSAPI version of GetParentPID, I had put hLib instead of hlib and because it was a lib file ofcourse the compiler doesn't throw an error. I have gone through the file and fixed the offending parts. Also the GetParentPID9x function had some problems,it seems that Win95 does not list the main module as the first in the module list at all times, so it was returning bizarre PIDs, also fixed.

There is a new upload at my website, sorry about that :(
Posted on 2004-07-04 04:37:24 by donkey