Everhart,Glenn From: aflent@orca.com Sent: Tuesday, April 14, 1998 4:03 PM To: Nathan Nesbit; ntdev@atria.com Subject: RE: [ntdev] Adding custom Traps and System Calls to Windows NT !> From: Nathan Nesbit !> To: "'Arthur Lent'" !> Subject: RE: [ntdev] Adding custom Traps and System Calls to Windows NT !> Date: Tue, 14 Apr 1998 12:06:11 -0700 !> !> !> I don't know about adding traps and system calls from a 3rd party !> perspective. But let me see if I can help. !> !> You have a kernel mode driver. You want functions in the driver to be !> exported to user mode applications. !> !> Well you can handle this in a couple ways I think. First of all if they are !> standard interface calls then the kernel should call your driver for the !> application. I.e. a file system driver exports it's read function to the io !> manager, which is then exposed to applications with NtReadFile, instead of !> the driver exporting it's functions directly to the app. !> !> Of course I think that you would not be asking your question if you wanted !> to only export standard functionality. !> !> One thing I've heard of people doing is exporting driver specific functions !> with DeviceIoControl. The handle tells the IO manager what driver to call. !> You can define however many FSCTLs are you want that apply to only your !> driver. (They really only have to be unqiue within your driver, but to be !> "safe" you might want to try and make them unquice with respect to other !> FSCTLs), The limitation with this is that it can only pass a buffer for !> input and a buffer for output. Of course if worse comes to worse, you could !> define the structure of the buffer(s). !> I.e. buffer = struct !> { !> int myvar1; !> char myvar2; !> } !> You could then "wrap" this with functions exported by a DLL. It can package !> the parameters it receives, calls DeviceIoControl on your buffer, and then !> unpackages return values. !> !> This would be a standard way that should work on NT 4 & 5. !> !> I've also heard of people communicating with drivers via shared memory, but !> this seems like a hack to me. Named pipes could also work. !> !> I think what you might want to do is post a question that asks how to export !> driver specific functionality to user mode apps. You might get some ideas !> that will work much better than adding a trap or fooling with the System !> Call table. !> !> As the system call table is undocumented you have no guarentee that what !> works with NT4 will not work with NT5. And what is even worse is that your !> stuff might break when service packs are installed. !> !> I don't believe that there is a way to add your own trap. And let me tell !> you why. If a driver is allowed to add a trap you could get the situation !> where driver A and driver B both want the same trap. So it would be first !> come, first served. It wouldn't be a good thing for your driver to be !> unable to function because some arbitrary driver loaded first. This could !> be solved by a dynamic trap assignment, but now you have to notify code that !> calls the trap what the trap number is this time. This could bring up even !> more problems in addition to adding overheard to application & driver code. !> Another problem could be what is the maximum number of traps available, !> etc... !> !> As I said before, I don't develop drivers and don't know much about how a !> driver should communicate with applications, beyond the standard win32 API. !> But it seems to me that DeviceIoControl is a standard way of allowing !> drivers to export custom functionality to applications. Buffers can be !> structured to help pass information. You can even wrap it with some !> functions that can be exported by a DLL made to communicate with your driver !> (you would probably do this anyway if you could add system calls). !> !> Good Luck. I suppose the best advise I can give you is to think over what !> is it you want to accomplish, and ask that question (export driver !> functionality). As opposed to asking how to do a particular action (how to !> add a system call to the table). !> !> Nathan Nesbit !> Software Design Engineer !> NT Core Test Nathan, Thank you very much for your detailed response to my question. I agree with you wholeheartedly that there are good ways to export driver functionality via documented interfaces such as DeviceIoControl. I also agree with you that shared memory is possible, albeit somewhat hack-ish. I hadn't considered named pipes but those, too, could be used. The problem is, I want to do some very specific, quite non-driverish things. And I want to do them as quickly as feasible; i.e., I want to transition from user-mode to kernel-mode more quickly than can be done by invoking DeviceIoControl and winding up inside my driver. I am already familiar with the NT facilities you mention; I am now looking for a facility comparable to Unix "loadable system calls". For instance, under Solaris, Digital Unix, etc., I can package code into an entity that can be dynamically loaded into the kernel. As part of this process, a system call number is assigned to the new call. I can then use this system call number in my application to invoke the new system call I created. Two applications simultaneously wishing to create system calls will be handled gracefully by the operating system, which will assign each new system call a separate system call number. No involvement is required by a device driver. The applications simply use the system call numbers returned by the dynamic loading process. I wish to do the same thing under NT. I'd like to do it for system calls and I'd also like to do it for traps. As I mentioned above, I'm looking to "go fast" from user-mode to kernel-mode. Are there any documented APIs in Windows NT that provide the ability to create my own system calls and/or traps? Thank you for all your help! Thanks, Arthur Lent. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ]