We are poring our drivers and applications to XP x64.
The driver has been ported to 64-bit. But we don’t want to re-compile the
app’s source code to 64-bit version. So, is it possible to make a 64-bit dll
which interprets data between 32-bit applications and 64-bit drivers?
In the section “Reasons for 64/32 Restrictions” of 2K3 SP1 SDK document, it
says that this is impossible. But I am not sure. Could anybody clarify this
for me? Or is there any other solutions?
Any hints are welcome. Thanks in advance.
–
Regards,
ZG [@ Sydney]
Windows Driver Developer
[Remove ‘stopspam’ & ‘nospam’ when you send email to me]
The solution is that your driver (not your application) should deal directly
with the 64/32 ‘bitness’ of any client application using the driver.
There are essentially two ways to address this goal:
Design your driver interface (Read/Write/DeviceIoControl) in such a way
that pointer-sized ‘values’ are never passed between your driver and the
user-mode client. If you can do this, your driver will simply just ‘work’
for either client type (32 or 64). NT will do all of the work for you for
any of the ‘pointer’ parameters passed to Read, Write, or DeviceIoControl.
Make your driver aware of the requestor’s bitness. This would be the
case, for instance, if your application passes pointer sized ‘addresses’ by
value into your driver for some reason and it actually needs to dereference
them, store them, give them back, etc. The problem here is that the width
of the value will change depending on the bitness of the client application.
WHDC has some articles and a PowerPoint on moving to 64bit (drivers). Check
out http://www.microsoft.com/whdc/default.mspx as well as the MSDN/DDK
documents. They too have some articles on supporting 32bit applications
with 64bit drivers.
The bottom line is this: The reason building your own ‘thunk’ cannot be
done is that it does not need to be done. The driver is fully responsible
for dealing with the IOCTL interface exposed for both 32bit and 64bit
clients. The system deals with the ‘system’ interfaces automatically
thunking parameter addresses, callbacks, handles, etc. You must deal with
the specific shape of your drivers IOCTL interface in the driver and not in
the application.
Good luck,
Dave Cattley
Consulting Engineer
Systems Software Development
“ZG” wrote in message news:xxxxx@ntdev… > Hi all, > > We are poring our drivers and applications to XP x64. > > The driver has been ported to 64-bit. But we don’t want to re-compile the > app’s source code to 64-bit version. So, is it possible to make a 64-bit > dll which interprets data between 32-bit applications and 64-bit drivers? > > In the section “Reasons for 64/32 Restrictions” of 2K3 SP1 SDK document, > it says that this is impossible. But I am not sure. Could anybody clarify > this for me? Or is there any other solutions? > > Any hints are welcome. Thanks in advance. > > – > > Regards, > ZG [@ Sydney] > Windows Driver Developer > [Remove ‘stopspam’ & ‘nospam’ when you send email to me] > >
The solution is that your driver (not your application) should deal directly
with the 64/32 ‘bitness’ of any client application using the driver.
There are essentially two ways to address this goal:
Design your driver interface (Read/Write/DeviceIoControl) in such a way
that pointer-sized ‘values’ are never passed between your driver and the
user-mode client. If you can do this, your driver will simply just ‘work’
for either client type (32 or 64). NT will do all of the work for you for
any of the ‘pointer’ parameters passed to Read, Write, or DeviceIoControl.
Make your driver aware of the requestor’s bitness. This would be the
case, for instance, if your application passes pointer sized ‘addresses’ by
value into your driver for some reason and it actually needs to dereference
them, store them, give them back, etc. The problem here is that the width
of the value will change depending on the bitness of the client application.
WHDC has some articles and a PowerPoint on moving to 64bit (drivers). Check
out http://www.microsoft.com/whdc/default.mspx as well as the MSDN/DDK
documents. They too have some articles on supporting 32bit applications
with 64bit drivers.
The bottom line is this: The reason building your own ‘thunk’ cannot be
done is that it does not need to be done. The driver is fully responsible
for dealing with the IOCTL interface exposed for both 32bit and 64bit
clients. The system deals with the ‘system’ interfaces automatically
thunking parameter addresses, callbacks, handles, etc. You must deal with
the specific shape of your drivers IOCTL interface in the driver and not in
the application.
Good luck,
Dave Cattley
Consulting Engineer
Systems Software Development
“ZG” wrote in message news:xxxxx@ntdev… > Hi all, > > We are poring our drivers and applications to XP x64. > > The driver has been ported to 64-bit. But we don’t want to re-compile the > app’s source code to 64-bit version. So, is it possible to make a 64-bit > dll which interprets data between 32-bit applications and 64-bit drivers? > > In the section “Reasons for 64/32 Restrictions” of 2K3 SP1 SDK document, > it says that this is impossible. But I am not sure. Could anybody clarify > this for me? Or is there any other solutions? > > Any hints are welcome. Thanks in advance. > > – > > Regards, > ZG [@ Sydney] > Windows Driver Developer > [Remove ‘stopspam’ & ‘nospam’ when you send email to me] > >
Unfortunately, our applications *must* pass pointers to buffers allocated in
user-mode to drivers. So, how to change a 32-bit address to a 64-bit address
if i don’t add a 32-64 translation layer? Just by testing that bit in IOCTL
codes? I don’t think it’s possible.
–
Regards,
ZG [@ Sydney]
Windows Driver Developer
[Remove ‘stopspam’ & ‘nospam’ when you send email to me]
“David R. Cattley” wrote in message news:xxxxx@ntdev… > ZG, > > The solution is that your driver (not your application) should deal > directly > with the 64/32 ‘bitness’ of any client application using the driver. > > There are essentially two ways to address this goal: > > 1. Design your driver interface (Read/Write/DeviceIoControl) in such a > way > that pointer-sized ‘values’ are never passed between your driver and the > user-mode client. If you can do this, your driver will simply just ‘work’ > for either client type (32 or 64). NT will do all of the work for you for > any of the ‘pointer’ parameters passed to Read, Write, or DeviceIoControl. > > 2. Make your driver aware of the requestor’s bitness. This would be the > case, for instance, if your application passes pointer sized ‘addresses’ > by > value into your driver for some reason and it actually needs to > dereference > them, store them, give them back, etc. The problem here is that the width > of the value will change depending on the bitness of the client > application. > > WHDC has some articles and a PowerPoint on moving to 64bit (drivers). > Check > out http://www.microsoft.com/whdc/default.mspx as well as the MSDN/DDK > documents. They too have some articles on supporting 32bit applications > with 64bit drivers. > > The bottom line is this: The reason building your own ‘thunk’ cannot be > done is that it does not need to be done. The driver is fully responsible > for dealing with the IOCTL interface exposed for both 32bit and 64bit > clients. The system deals with the ‘system’ interfaces automatically > thunking parameter addresses, callbacks, handles, etc. You must deal with > the specific shape of your drivers IOCTL interface in the driver and not > in > the application. > > Good luck, > Dave Cattley > Consulting Engineer > Systems Software Development > > “ZG” wrote in message news:xxxxx@ntdev… >> Hi all, >> >> We are poring our drivers and applications to XP x64. >> >> The driver has been ported to 64-bit. But we don’t want to re-compile the >> app’s source code to 64-bit version. So, is it possible to make a 64-bit >> dll which interprets data between 32-bit applications and 64-bit drivers? >> >> In the section “Reasons for 64/32 Restrictions” of 2K3 SP1 SDK document, >> it says that this is impossible. But I am not sure. Could anybody clarify >> this for me? Or is there any other solutions? >> >> Any hints are welcome. Thanks in advance. >> >> – >> >> Regards, >> ZG [@ Sydney] >> Windows Driver Developer >> [Remove ‘stopspam’ & ‘nospam’ when you send email to me] >> >> > > >
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“ZG” wrote in message news:xxxxx@ntdev… > Thanks David. > > Unfortunately, our applications must pass pointers to buffers allocated > in user-mode to drivers. So, how to change a 32-bit address to a 64-bit > address if i don’t add a 32-64 translation layer? Just by testing that bit > in IOCTL codes? I don’t think it’s possible. > > – > > Regards, > ZG [@ Sydney] > Windows Driver Developer > [Remove ‘stopspam’ & ‘nospam’ when you send email to me] > > > “David R. Cattley” wrote in message news:xxxxx@ntdev… >> ZG, >> >> The solution is that your driver (not your application) should deal >> directly >> with the 64/32 ‘bitness’ of any client application using the driver. >> >> There are essentially two ways to address this goal: >> >> 1. Design your driver interface (Read/Write/DeviceIoControl) in such a >> way >> that pointer-sized ‘values’ are never passed between your driver and the >> user-mode client. If you can do this, your driver will simply just >> ‘work’ >> for either client type (32 or 64). NT will do all of the work for you >> for >> any of the ‘pointer’ parameters passed to Read, Write, or >> DeviceIoControl. >> >> 2. Make your driver aware of the requestor’s bitness. This would be the >> case, for instance, if your application passes pointer sized ‘addresses’ >> by >> value into your driver for some reason and it actually needs to >> dereference >> them, store them, give them back, etc. The problem here is that the >> width >> of the value will change depending on the bitness of the client >> application. >> >> WHDC has some articles and a PowerPoint on moving to 64bit (drivers). >> Check >> out http://www.microsoft.com/whdc/default.mspx as well as the MSDN/DDK >> documents. They too have some articles on supporting 32bit applications >> with 64bit drivers. >> >> The bottom line is this: The reason building your own ‘thunk’ cannot be >> done is that it does not need to be done. The driver is fully >> responsible >> for dealing with the IOCTL interface exposed for both 32bit and 64bit >> clients. The system deals with the ‘system’ interfaces automatically >> thunking parameter addresses, callbacks, handles, etc. You must deal >> with >> the specific shape of your drivers IOCTL interface in the driver and not >> in >> the application. >> >> Good luck, >> Dave Cattley >> Consulting Engineer >> Systems Software Development >> >> “ZG” wrote in message news:xxxxx@ntdev… >>> Hi all, >>> >>> We are poring our drivers and applications to XP x64. >>> >>> The driver has been ported to 64-bit. But we don’t want to re-compile >>> the app’s source code to 64-bit version. So, is it possible to make a >>> 64-bit dll which interprets data between 32-bit applications and 64-bit >>> drivers? >>> >>> In the section “Reasons for 64/32 Restrictions” of 2K3 SP1 SDK document, >>> it says that this is impossible. But I am not sure. Could anybody >>> clarify this for me? Or is there any other solutions? >>> >>> Any hints are welcome. Thanks in advance. >>> >>> – >>> >>> Regards, >>> ZG [@ Sydney] >>> Windows Driver Developer >>> [Remove ‘stopspam’ & ‘nospam’ when you send email to me] >>> >>> >> >> >> > > >
The operation you need to convert a 32-bit address to a 64-bit address in
the driver is simply a cast from the appropriate POINTER_32 decorated type
to a ‘native’ 64bit pointer type. The compiler will extend the pointer to
64bits. That is all the translation layer necessary.
If you are chasing pointers in complex connected datastructures, you will
essentially end up with two logic layers in your driver; one that processes
the 32bit version of the data structures for 32bit clients and one that
processes the 64bit versions for 64bit clients.
You will just need to have a way of knowing (see previously referenced
articles and DDK docs) what layout of the pararmeters to process (32bit or
64bit) in any given IOCTL.
I wont for an instant presume to know the ‘answer’ for your driver. In a
driver I just ported for a client, however, the approach was to recode the
IOCTL interface to transfer ownership of the complex data structures to the
driver and to redefine the interface used by the client application as a set
of access methods. This avoided having to have the driver figure out what
datastructure to traverse. This may not be possible in your case if the
user-mode interface cannot change. If you user-mode interface, however is a
DLL access layer, perhaps the IOCTL shape can change…
Good luck,
Dave Cattley
Consulting Engineer
Systems Software Development
“ZG” wrote in message news:xxxxx@ntdev… > Thanks David. > > Unfortunately, our applications must pass pointers to buffers allocated > in user-mode to drivers. So, how to change a 32-bit address to a 64-bit > address if i don’t add a 32-64 translation layer? Just by testing that bit > in IOCTL codes? I don’t think it’s possible. > > – > > Regards, > ZG [@ Sydney] > Windows Driver Developer > [Remove ‘stopspam’ & ‘nospam’ when you send email to me] > >
If you haven’t changed (or recompiled) your application you *know* that it
is passing 32-bit pointers.
If you have recompiled your application, then the size of the input
parameter to the IOCTL will have increased by at least 4 bytes to account
for the pointer getting larger.
You said earlier you didn’t want to recompile the application. So it shoudl
still be passing 32 bit pointers. If you did decide to recompile, I’d make
a new IOCTL number that was for 64 bit pointers and change the number being
passed by the program. The driver presumably could then check for the
expected parameter size and match it against the ioctl number for validity.
Regards,
ZG [@ Sydney]
Windows Driver Developer
[Remove ‘stopspam’ & ‘nospam’ when you send email to me]
“Don Burn” wrote in message news:xxxxx@ntdev… > Look at the OSR article http://www.osronline.com/article.cfm?article=265 > they discuss this problem and solutions. > > > – > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > Remove StopSpam from the email to reply > > > > > “ZG” wrote in message news:xxxxx@ntdev… >> Thanks David. >> >> Unfortunately, our applications must pass pointers to buffers allocated >> in user-mode to drivers. So, how to change a 32-bit address to a 64-bit >> address if i don’t add a 32-64 translation layer? Just by testing that >> bit in IOCTL codes? I don’t think it’s possible. >> >> – >> >> Regards, >> ZG [@ Sydney] >> Windows Driver Developer >> [Remove ‘stopspam’ & ‘nospam’ when you send email to me] >> >> >> “David R. Cattley” wrote in message >> news:xxxxx@ntdev… >>> ZG, >>> >>> The solution is that your driver (not your application) should deal >>> directly >>> with the 64/32 ‘bitness’ of any client application using the driver. >>> >>> There are essentially two ways to address this goal: >>> >>> 1. Design your driver interface (Read/Write/DeviceIoControl) in such a >>> way >>> that pointer-sized ‘values’ are never passed between your driver and the >>> user-mode client. If you can do this, your driver will simply just >>> ‘work’ >>> for either client type (32 or 64). NT will do all of the work for you >>> for >>> any of the ‘pointer’ parameters passed to Read, Write, or >>> DeviceIoControl. >>> >>> 2. Make your driver aware of the requestor’s bitness. This would be >>> the >>> case, for instance, if your application passes pointer sized ‘addresses’ >>> by >>> value into your driver for some reason and it actually needs to >>> dereference >>> them, store them, give them back, etc. The problem here is that the >>> width >>> of the value will change depending on the bitness of the client >>> application. >>> >>> WHDC has some articles and a PowerPoint on moving to 64bit (drivers). >>> Check >>> out http://www.microsoft.com/whdc/default.mspx as well as the MSDN/DDK >>> documents. They too have some articles on supporting 32bit applications >>> with 64bit drivers. >>> >>> The bottom line is this: The reason building your own ‘thunk’ cannot be >>> done is that it does not need to be done. The driver is fully >>> responsible >>> for dealing with the IOCTL interface exposed for both 32bit and 64bit >>> clients. The system deals with the ‘system’ interfaces automatically >>> thunking parameter addresses, callbacks, handles, etc. You must deal >>> with >>> the specific shape of your drivers IOCTL interface in the driver and not >>> in >>> the application. >>> >>> Good luck, >>> Dave Cattley >>> Consulting Engineer >>> Systems Software Development >>> >>> “ZG” wrote in message news:xxxxx@ntdev… >>>> Hi all, >>>> >>>> We are poring our drivers and applications to XP x64. >>>> >>>> The driver has been ported to 64-bit. But we don’t want to re-compile >>>> the app’s source code to 64-bit version. So, is it possible to make a >>>> 64-bit dll which interprets data between 32-bit applications and 64-bit >>>> drivers? >>>> >>>> In the section “Reasons for 64/32 Restrictions” of 2K3 SP1 SDK >>>> document, it says that this is impossible. But I am not sure. Could >>>> anybody clarify this for me? Or is there any other solutions? >>>> >>>> Any hints are welcome. Thanks in advance. >>>> >>>> – >>>> >>>> Regards, >>>> ZG [@ Sydney] >>>> Windows Driver Developer >>>> [Remove ‘stopspam’ & ‘nospam’ when you send email to me] >>>> >>>> >>> >>> >>> >> >> >> > > >
“David R. Cattley” wrote in message news:xxxxx@ntdev… > datastructure to traverse. This may not be possible in your case if the > user-mode interface cannot change. If you user-mode interface, however is > a
Yes. This is our problem. User-mode guys and SDK clients don’t want to change their codes too much.
–
Regards, ZG [@ Sydney] Windows Driver Developer [Remove ‘stopspam’ & ‘nospam’ when you send email to me]
We don’t want to re-compile our application. So, it’s still 32-bit.
–
Regards,
ZG [@ Sydney]
Windows Driver Developer
[Remove ‘stopspam’ & ‘nospam’ when you send email to me]
“Loren Wilton” wrote in message news:xxxxx@ntdev… > If you haven’t changed (or recompiled) your application you know that it > is passing 32-bit pointers. > > If you have recompiled your application, then the size of the input > parameter to the IOCTL will have increased by at least 4 bytes to account > for the pointer getting larger. > > You said earlier you didn’t want to recompile the application. So it > shoudl > still be passing 32 bit pointers. If you did decide to recompile, I’d > make > a new IOCTL number that was for 64 bit pointers and change the number > being > passed by the program. The driver presumably could then check for the > expected parameter size and match it against the ioctl number for > validity. > > Loren > >
According to “…Of course, for 32-bit apps, the SecondaryBuffer pointer
will be 32 bits long and for 64-bit apps the SecondaryBuffer pointer will be
64 bits long…” in this article, if my driver gets a 32-bit address in the
input structure, is this address valid for Mmxxx and Probxxxx functions?
–
Regards,
ZG [@ Sydney]
Windows Driver Developer
[Remove ‘stopspam’ & ‘nospam’ when you send email to me]
“Don Burn” wrote in message news:xxxxx@ntdev… > Look at the OSR article http://www.osronline.com/article.cfm?article=265 > they discuss this problem and solutions. > > > – > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > Remove StopSpam from the email to reply > > > > > “ZG” wrote in message news:xxxxx@ntdev… >> Thanks David. >> >> Unfortunately, our applications must pass pointers to buffers allocated >> in user-mode to drivers. So, how to change a 32-bit address to a 64-bit >> address if i don’t add a 32-64 translation layer? Just by testing that >> bit in IOCTL codes? I don’t think it’s possible. >> >> – >> >> Regards, >> ZG [@ Sydney] >> Windows Driver Developer >> [Remove ‘stopspam’ & ‘nospam’ when you send email to me] >> >> >> “David R. Cattley” wrote in message >> news:xxxxx@ntdev… >>> ZG, >>> >>> The solution is that your driver (not your application) should deal >>> directly >>> with the 64/32 ‘bitness’ of any client application using the driver. >>> >>> There are essentially two ways to address this goal: >>> >>> 1. Design your driver interface (Read/Write/DeviceIoControl) in such a >>> way >>> that pointer-sized ‘values’ are never passed between your driver and the >>> user-mode client. If you can do this, your driver will simply just >>> ‘work’ >>> for either client type (32 or 64). NT will do all of the work for you >>> for >>> any of the ‘pointer’ parameters passed to Read, Write, or >>> DeviceIoControl. >>> >>> 2. Make your driver aware of the requestor’s bitness. This would be >>> the >>> case, for instance, if your application passes pointer sized ‘addresses’ >>> by >>> value into your driver for some reason and it actually needs to >>> dereference >>> them, store them, give them back, etc. The problem here is that the >>> width >>> of the value will change depending on the bitness of the client >>> application. >>> >>> WHDC has some articles and a PowerPoint on moving to 64bit (drivers). >>> Check >>> out http://www.microsoft.com/whdc/default.mspx as well as the MSDN/DDK >>> documents. They too have some articles on supporting 32bit applications >>> with 64bit drivers. >>> >>> The bottom line is this: The reason building your own ‘thunk’ cannot be >>> done is that it does not need to be done. The driver is fully >>> responsible >>> for dealing with the IOCTL interface exposed for both 32bit and 64bit >>> clients. The system deals with the ‘system’ interfaces automatically >>> thunking parameter addresses, callbacks, handles, etc. You must deal >>> with >>> the specific shape of your drivers IOCTL interface in the driver and not >>> in >>> the application. >>> >>> Good luck, >>> Dave Cattley >>> Consulting Engineer >>> Systems Software Development >>> >>> “ZG” wrote in message news:xxxxx@ntdev… >>>> Hi all, >>>> >>>> We are poring our drivers and applications to XP x64. >>>> >>>> The driver has been ported to 64-bit. But we don’t want to re-compile >>>> the app’s source code to 64-bit version. So, is it possible to make a >>>> 64-bit dll which interprets data between 32-bit applications and 64-bit >>>> drivers? >>>> >>>> In the section “Reasons for 64/32 Restrictions” of 2K3 SP1 SDK >>>> document, it says that this is impossible. But I am not sure. Could >>>> anybody clarify this for me? Or is there any other solutions? >>>> >>>> Any hints are welcome. Thanks in advance. >>>> >>>> – >>>> >>>> Regards, >>>> ZG [@ Sydney] >>>> Windows Driver Developer >>>> [Remove ‘stopspam’ & ‘nospam’ when you send email to me] >>>> >>>> >>> >>> >>> >> >> >> > > >