C-Library function wrapper for use with DDK?
 

Anyone happen to have a nice collection of C-Library function wrappers for use with the Windows DDK? I am aware of those that exist in libcntpr.lib, but it is limited to string manipulation and does not contain such functions as the following:

(f)read, (f)write, (f)open, (f)close, malloc, free and fstat

Anyone with pointers to some source would be greatly appreciated.

NT/2k/XP Drivers Development Kit is all what you need. What are those wrappers for ?! If you want to be a friend of the system you have to use standart function for file read/write/open/close operations such as ZwReadFile/ZwWriteFile/ZwOpen/ZwClose. For memory de/allocation you could use ExFreePool/ExAllocatePoolWithTag. For fstat function probably you could use ZwQueryInformationFile.

I'm glad if it is somehow pointed to the source you wanted...

I'm aware of ZwReadFile and company -- what I am after is a quick means of porting use rmode code to kernel mode by wrapping ZwReadFile, etc with fread, etc, thus being able to theoretically recompile user mode code into usable kernel code. Albeit, there are caveats a plenty, but it should work more often than not.

Ex:

#define FILE HANDLE

FILE *fopen(const char *path, const char *mode)
{
HANDLE file;
...
...
status = ZwCreateFile(&file, ...);
...

return file;
}

I am actually most of the way through implementing this approach as a library and then just linking it in to my drivers as needed.

IMHO, it is rather strange idea. But if you have been dealing with it for a long time I think you could write those wrappers for that 7 functions by yourself -- as far as I undersrood it is not so hard or I am mistaken?

And some point to source :) -- If smth can go wrong it will..

It is simply a means of reducing development time and will allow me to prototype an idea in user mode -- which is infinitely easier -- then bring it into kernel mode for final "packaging."

I am actually finished with the 7 wrappers, just going through and stress testing them with a test suite.

Basically, I was being lazy and asking. Always helpful to start from someone else's end point than to begin with a blank slate. But, alas, it was probably better to just do it myself :)

Experienced system software developer in my opinion has no need in such a library. But for a newbie in driver development maybe it could somehow help to lay down from um to km...

It is like to develop drivers with help of Jungo/WinDriver/etc. or DriverStudio. However the last one could be used as a test/debug suite...

P.S. It is all my IMHO ;)

Experience has nothing to do with this -- practicality has everything to do with it. Rapid prototyping is rapid prototyping -- getting the semantics of a ZwCreateFile right _once_ and writing an interface to it guarantees avoidance of any development issues, etc.

Jungo, etc. are absolutely not the same. This is an exceedingly thin layer of code, where as Jungo etc are rather nasty and bring about more problems than they solve. Implementing my solution requires knowledge of the low-level system, they do not.

This is coming from someone with about 12 years of low-level software design and development, not to mention a lot of experieince in rapid development and deployment of various solutions.

I don't disagree with what you said thewhiz, but why do you need to write a driver if the code runs in user-mode ? I don't think you can test a wide range of functionality by doing that. There are a lot of driver-only issues (the hard ones, too), that simply do not exist in user-mode (the entire IRQL issue for instance).

Infinite number of reasons. Algorithm testing in user-mode for instance. There are definitely kernel-mode issues that must be addressed, but given I am doing a finite number of wrappers and a lot of what I am concerned with are pure algorithms, it is not a big deal. IRQL issues come with I/O in my case and as such those are finite issues.

Msvcrt wrapper
 

@thewhiz
Probably this is what you want :D

regards.

I don't think that's what thewhizz wants, he needs a wrapper library to wrap the DDK (Driver Development Kit) libraries so as to be able to use standard C library function.

@thewhizz, good idea to do this, I think it's a good way to first detect the bugs related to the algorithm before having to deal with the bugs specific to driver development. Unfortunately, I do not have such a wrapper library but I would be very interested in one.
Sorry that I can't be of much help