device driver

    Sponsored Links


  • 1. how to write data on USB from kernel space
    Hi I have a network protocol filter driver and from this I need to write all the data i get from network on USB port. Any hints how can i write on USB from my protocol driver. ? regards, John
  • 2. Using a single inf file for both 32- and 64-bit KMDF windows drive
    Hi, has anyone done something like supporting both types of drivers using a single inf in a directory like drivers\ and put the actual drivers in two subdirectories like drivers\32bit\ and drivers\4bit\ for these KMDF drivers? According to KMDF help file, it seems to require inf, drivers and KMDF coinstaller to be in the same directory. Has anyone here done something different? Thanks. AT
  • 3. Convert float to int
    I am compiling code using the WinDDK compiler since I am trying to create a low-level kernel-mode driver. The errors I am getting during compilation are: aes.obj : error LNK2019: unresolved external symbol __ftol2 referenced in function "public: void __thiscall AES::createIV(void)" (?createIV@AES@@QAEXXZ) aes.obj : error LNK2019: unresolved external symbol ___CxxFrameHandler referenced in function __ehhandler$?createIV@AES@@QAEXXZ When I remove this line: ran_num = loc_rng.ran(); where ran_num is declared as: double ran_num; and the ran() method returns a double. That line gives the error: aes.obj : error LNK2019: unresolved external symbol ___CxxFrameHandler referenced in function __ehhandler$?createIV@AES@@QAEXXZ --------------------------- The line: int_ran_num = (int)float_ran_num; where int_ran_num is declared as an integer and float_ran_num is declared as float. The error: aes.obj : error LNK2019: unresolved external symbol __ftol2 referenced in function "public: void __thiscall AES::createIV(void)" (?createIV@AES@@QAEXXZ) is generated from the above line. Also, Does anyone know how to convert a floating point number to an integer in Kernel-mode? The conversion is one of the problems I'm having. -Jay
  • 4. IoGetDeviceObjectPointer and zombie drive
    Hi, It seems that by calling this IoGetDeviceObjectPointer with different params causes zombie drives to appear. Zombie drives are drives that still appears when you call GetLogicalDrives() in user mode although it's been plugged out (usb for e.g.). The difference of params is DesiredAccess, which with value 0, zombie drives appear, but with FILE_READ_DATA, it seems to be working fine. The problem with feeding FILE_READ_DATA is that at times it will fail, with STATUS_SHARING_VIOLATION. I hope someone could shed some light on this. Could it be a bug of that call? thanks in advance. -- EWK Liew


Postby Meier Rudolf » Thu, 06 Oct 2005 17:55:19 GMT


I don't have a problem, but I'd like to understand this. If the 
'DrvConvertDevMode' of my printer driver get's the CDM_DRIVER_DEFAULT value, 
it should return the driver's default values... now, let's assume that I've 
a printer driver that can handle 2 types of printers. One is a A4 and the 
other one a A2 printer (that's the most significant difference). When the 
driver is called, the printer name passed to it, is not a printer name, but 
something like this "manufacturer drivername". So, my driver has no chance 
to find out, if windows want's the informations about the A4 or the A2 
printer. So, it can't insert the correct data about papersize, resolution 
etc. ... could this be a problem? Does Windows ever use the data received by 
this call? I don't think so... I think, that Windows never uses the 
CDM_DRIVER_DEFAULT values... am I right? Or do I have to solve this problem?
What, if the printer is attached to the network and I can't return correct 
values, if I can't communicate with it? (so, then it's impossible to say 
something about standard values, if I don't have the printers name)...


Similar Threads:

1.Shared printer driver and DrvConvertDevmode

I'm having a problem with my monolithic, user mode 
printer driver.  The problem is: The driver is installed 
on windows 2000 server or windows 2003 server and shared.
An XP client connects to it.  When the user on the client 
attempts to change printer properties, the changes are 
not saved.

I think it is caused by a problem I am having handling 
DrvConvertDevmode's CMD_DRIVER_DEFAULT.  In the driver, I 
attempt to save the devmode by doing a SetPrinter with a 
PRINTER_INFO_2 structure.  As soon as I call it, Windows 
calls my driver's DrvConvertDevmode, with *pcbNeeded=0 
and pdmOut=NULL.  I fill in *pcbNeeded with the size of 
my devmode and return FALSE.  Windows immediately calls 
me back, with *pcbNeeded=0 and pdmOut=NULL again.

I expect that windows should call me back the second time 
with *pcbNeeded=<size of my devmode> and pdmOut=<pointer 
to a devmode-sized piece of memory>.

Is there something that I am misunderstanding?

Scott Robins

2.DrvConvertDevmode + CreateThread


Simple Question: Can I call CreateThread in the DrvConvertDevmode function 
of my printer driver or not? ... second question (if the answer is no): Why?

-> Please no speculations...


Return to device driver


Who is online

Users browsing this forum: No registered users and 76 guest