Hi,
I wrote driver codes for a device to run under win 7 64 bit and it works. I have an application(a service) to communicate this device via PCI-Ex. But application is 32 bit(works via system files under systemWOW64). Can i use this application?
Note : According to some documents; i can not use 32 bit application if app reaches the kernel mode.
You can, though there is the potential for some issues with IOCTL’s, but
these can all be addressed.
See the wdk docs for ‘64-bit issues.’
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@netas.com.tr
Sent: Wednesday, March 09, 2011 5:47 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] 32 bit application for 64 bit driver
Hi,
I wrote driver codes for a device to run under win 7 64 bit and it works. I
have an application(a service) to communicate this device via PCI-Ex. But
application is 32 bit(works via system files under systemWOW64). Can i use
this application?
Note : According to some documents; i can not use 32 bit application if app
reaches the kernel mode.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
There were a recent topic in this list regarding 32 bit helper app vs 64bit driver. It had some useful comments.
Thanks for docs;
One more question…
32 bit programmes which run under 64 bit use the system files under
systemWOW64(as my app), but I want it use the system files under
system32. How can I force it?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@shcherbyna.com
Sent: Wednesday, March 09, 2011 1:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] 32 bit application for 64 bit driver
There were a recent topic in this list regarding 32 bit helper app vs
64bit driver. It had some useful comments.
http://www.osronline.com/showThread.cfm?link=198729
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
What “system file” do you need?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Osman TOKER” wrote in message news:xxxxx@ntdev…
Thanks for docs;
One more question…
32 bit programmes which run under 64 bit use the system files under
systemWOW64(as my app), but I want it use the system files under
system32. How can I force it?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@shcherbyna.com
Sent: Wednesday, March 09, 2011 1:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] 32 bit application for 64 bit driver
There were a recent topic in this list regarding 32 bit helper app vs
64bit driver. It had some useful comments.
http://www.osronline.com/showThread.cfm?link=198729
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I mean .dll files for application.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Thursday, March 10, 2011 12:56 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] 32 bit application for 64 bit driver
What “system file” do you need?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Osman TOKER” wrote in message
news:xxxxx@ntdev…
Thanks for docs;
One more question…
32 bit programmes which run under 64 bit use the system files under
systemWOW64(as my app), but I want it use the system files under
system32. How can I force it?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@shcherbyna.com
Sent: Wednesday, March 09, 2011 1:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] 32 bit application for 64 bit driver
There were a recent topic in this list regarding 32 bit helper app vs
64bit driver. It had some useful comments.
http://www.osronline.com/showThread.cfm?link=198729
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Why do you need 64bit DLLs in the 32bit app?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Osman TOKER” wrote in message news:xxxxx@ntdev…
I mean .dll files for application.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Thursday, March 10, 2011 12:56 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] 32 bit application for 64 bit driver
What “system file” do you need?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Osman TOKER” wrote in message
news:xxxxx@ntdev…
Thanks for docs;
One more question…
32 bit programmes which run under 64 bit use the system files under
systemWOW64(as my app), but I want it use the system files under
system32. How can I force it?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@shcherbyna.com
Sent: Wednesday, March 09, 2011 1:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] 32 bit application for 64 bit driver
There were a recent topic in this list regarding 32 bit helper app vs
64bit driver. It had some useful comments.
http://www.osronline.com/showThread.cfm?link=198729
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hi,
You can disable the Wow64 File System Redirection by using this routine:
BOOL WINAPI Wow64DisableWow64FsRedirection(
__out PVOID *OldValue
);
Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br/en
I think there is a problem about base adresses; DLL files is a bridge of
driver codes and application. This addresses is 64 bit in the kernel
mode but they defined as 32 bit in the DLL. If application use them, it
takes the wrong addresses. (BSOD: mov rax, qword ptr[rax+r8*2].
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Thursday, March 10, 2011 1:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] 32 bit application for 64 bit driver
Why do you need 64bit DLLs in the 32bit app?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Osman TOKER” wrote in message
news:xxxxx@ntdev…
I mean .dll files for application.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Thursday, March 10, 2011 12:56 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] 32 bit application for 64 bit driver
What “system file” do you need?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Osman TOKER” wrote in message
news:xxxxx@ntdev…
Thanks for docs;
One more question…
32 bit programmes which run under 64 bit use the system files under
systemWOW64(as my app), but I want it use the system files under
system32. How can I force it?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@shcherbyna.com
Sent: Wednesday, March 09, 2011 1:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] 32 bit application for 64 bit driver
There were a recent topic in this list regarding 32 bit helper app vs
64bit driver. It had some useful comments.
http://www.osronline.com/showThread.cfm?link=198729
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
So I think you’re saying that you want a 32-bit application to use a
64-bit DLL in order to talk to your driver, is that right ?
If so, you’re way out in the weeds.
The solution is to have a 32-bit version of your interface DLL and if
necessary within the driver resolve any 32/64 bit issues within the
received ioctls. There’s been plenty of discussion about this on the
list, so search the archves or go to WHDC.
As for naming and or placement of your 32-bit DLL, there are some
choices. If you name the 32 and 64 bit DLLS the same, then your
installer needs to be careful where it installs them so that they
don’t get mixed up. Personally, I prefer to let Microsoft keep the
system directories to themselves, but then I don’t do mass production
apps. In my case I prefer to create Interface32.dll and Interface64.dll.
My 32-bit applications (and user 32-bit applications using my SDK)
link against the stub library Interface32.lib and the 64-bit
applications against Interface64.lib. I’m sure there’s better ways,
but my clients can repackage my DLLs with apps they write to my interfaces.
The interface DLLs are common code and result in the same ioctls
being sent to the driver, just a few minor tweaks for bitness
differences and the rest is down to using 32 and 64 bit build environments.
Nothing hard here, certainly not compared to telling a 32-bit thread
to suddenly start using 64-bit code.
Mark.
At 11:40 10/03/2011, Osman TOKER wrote:
I mean .dll files for application.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Thursday, March 10, 2011 12:56 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] 32 bit application for 64 bit driverWhat “system file” do you need?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com“Osman TOKER” wrote in message
>news:xxxxx@ntdev…
>
>Thanks for docs;
>One more question…
>32 bit programmes which run under 64 bit use the system files under
>systemWOW64(as my app), but I want it use the system files under
>system32. How can I force it?
>
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of
>xxxxx@shcherbyna.com
>Sent: Wednesday, March 09, 2011 1:04 PM
>To: Windows System Software Devs Interest List
>Subject: RE:[ntdev] 32 bit application for 64 bit driver
>
>There were a recent topic in this list regarding 32 bit helper app vs
>64bit driver. It had some useful comments.
>
>http://www.osronline.com/showThread.cfm?link=198729
>
>—
>NTDEV is sponsored by OSR
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
>
>
>—
>NTDEV is sponsored by OSR
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
>
>—
>NTDEV is sponsored by OSR
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
Osman TOKER wrote:
I think there is a problem about base adresses; DLL files is a bridge of
driver codes and application. This addresses is 64 bit in the kernel
mode but they defined as 32 bit in the DLL. If application use them, it
takes the wrong addresses. (BSOD: mov rax, qword ptr[rax+r8*2].
You still misunderstand the situation here.
As I recall, you have a driver model in which the driver sends an
“address cookie” to the application, and the application hands that back
to the driver at a later point. Am I remembering correctly?
To use that model in a 64-bit system, the “address cookie” field MUST be
defined as a 64-bit type. It does not need to be a pointer, because the
user-mode application cannot do anything with that value. It’s just a
number with no meaning to the application, exactly like a window handle
or a file handle. You also cannot have it be something like a
DWORD_PTR, because that has a different size in a 32-bit app and a
64-bit app. The field must ALWAYS be 64-bits, regardless of the size of
the app or the size of the driver.
You need to remember how many different combinations there are, and be
prepared for all of them. You could have your 32-bit app call a 32-bit
driver, or a 32-bit app call a 64-bit driver, or a 64-bit app call a
64-bit driver. Your ioctl structure must handle all of those combinations.
That means you need to change the structures that you pass in your ioctl
so that the field is declared as “unsigned __int64” or “ULONGLONG”.
That applies everywhere. You will need to do that whether the
application is 32-bit or 64-bit. You could declare your own type for
this, like:
typedef unsigned __int64 MYHANDLE;
You CANNOT define this field as a “void *”, even in the driver. The
field must always be 64 bits. So, your driver will need to have code to
cast the value to a pointer before it can be used. When you have a
32-bit driver, the top half of the structure field will be 0, but it
MUST be there.
This means you now have a backwards compatibility problem. Once you
make that change, your application will not work with the drivers you
have already released. Because of that, you might want to change the
ioctl number to make sure there are no “accidents”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
In our design, there is extra dll file app used and it is out of my
control(edit) so it confused me. I changed everything you said in my
driver codes but it seems that dll files must be changed however
compiled under 64 bit system.
Osman
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, March 10, 2011 7:57 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 32 bit application for 64 bit driver
Osman TOKER wrote:
I think there is a problem about base adresses; DLL files is a bridge
of driver codes and application. This addresses is 64 bit in the
kernel mode but they defined as 32 bit in the DLL. If application use
them, it takes the wrong addresses. (BSOD: mov rax, qword
ptr[rax+r8*2].
You still misunderstand the situation here.
As I recall, you have a driver model in which the driver sends an
“address cookie” to the application, and the application hands that back
to the driver at a later point. Am I remembering correctly?
To use that model in a 64-bit system, the “address cookie” field MUST be
defined as a 64-bit type. It does not need to be a pointer, because the
user-mode application cannot do anything with that value. It’s just a
number with no meaning to the application, exactly like a window handle
or a file handle. You also cannot have it be something like a
DWORD_PTR, because that has a different size in a 32-bit app and a
64-bit app. The field must ALWAYS be 64-bits, regardless of the size of
the app or the size of the driver.
You need to remember how many different combinations there are, and be
prepared for all of them. You could have your 32-bit app call a 32-bit
driver, or a 32-bit app call a 64-bit driver, or a 64-bit app call a
64-bit driver. Your ioctl structure must handle all of those
combinations.
That means you need to change the structures that you pass in your ioctl
so that the field is declared as “unsigned __int64” or “ULONGLONG”.
That applies everywhere. You will need to do that whether the
application is 32-bit or 64-bit. You could declare your own type for
this, like:
typedef unsigned __int64 MYHANDLE;
You CANNOT define this field as a “void *”, even in the driver. The
field must always be 64 bits. So, your driver will need to have code to
cast the value to a pointer before it can be used. When you have a
32-bit driver, the top half of the structure field will be 0, but it
MUST be there.
This means you now have a backwards compatibility problem. Once you
make that change, your application will not work with the drivers you
have already released. Because of that, you might want to change the
ioctl number to make sure there are no “accidents”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Unless you can modify this interface DLL, there is no way for you to make
the interface work on x64.
It might be possible to redesign the driver to supply fake 32-bit values
to the UM DLL that cause it to pass back fake 32-bit values that you can use
(i.e. convert from a pointer to a handle), and IMHO this would be an
excellent change to your interface, but you will need to carefully study
your source to see if this is possible.
In this case, instead of ULONGLONG as Tim suggests, the field would be DWORD
or variant of unsigned __int32, but the principal is the same: a CONSTANT
size across all platforms.
It is also possible, as I previously mentioned to use a variable sized
structure to solve this problem; but if you can;t modify the DLL source then
I doubt that this is a viable option for you
“Osman TOKER” wrote in message news:xxxxx@ntdev…
In our design, there is extra dll file app used and it is out of my
control(edit) so it confused me. I changed everything you said in my
driver codes but it seems that dll files must be changed however
compiled under 64 bit system.
Osman
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, March 10, 2011 7:57 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 32 bit application for 64 bit driver
Osman TOKER wrote:
I think there is a problem about base adresses; DLL files is a bridge
of driver codes and application. This addresses is 64 bit in the
kernel mode but they defined as 32 bit in the DLL. If application use
them, it takes the wrong addresses. (BSOD: mov rax, qword
ptr[rax+r8*2].
You still misunderstand the situation here.
As I recall, you have a driver model in which the driver sends an
“address cookie” to the application, and the application hands that back
to the driver at a later point. Am I remembering correctly?
To use that model in a 64-bit system, the “address cookie” field MUST be
defined as a 64-bit type. It does not need to be a pointer, because the
user-mode application cannot do anything with that value. It’s just a
number with no meaning to the application, exactly like a window handle
or a file handle. You also cannot have it be something like a
DWORD_PTR, because that has a different size in a 32-bit app and a
64-bit app. The field must ALWAYS be 64-bits, regardless of the size of
the app or the size of the driver.
You need to remember how many different combinations there are, and be
prepared for all of them. You could have your 32-bit app call a 32-bit
driver, or a 32-bit app call a 64-bit driver, or a 64-bit app call a
64-bit driver. Your ioctl structure must handle all of those
combinations.
That means you need to change the structures that you pass in your ioctl
so that the field is declared as “unsigned __int64” or “ULONGLONG”.
That applies everywhere. You will need to do that whether the
application is 32-bit or 64-bit. You could declare your own type for
this, like:
typedef unsigned __int64 MYHANDLE;
You CANNOT define this field as a “void *”, even in the driver. The
field must always be 64 bits. So, your driver will need to have code to
cast the value to a pointer before it can be used. When you have a
32-bit driver, the top half of the structure field will be 0, but it
MUST be there.
This means you now have a backwards compatibility problem. Once you
make that change, your application will not work with the drivers you
have already released. Because of that, you might want to change the
ioctl number to make sure there are no “accidents”.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Observations:
The reason that there is file system redirection is that you can't use
64-bit DLLs in a 32-bit app. Furthermore, if they really ARE 32-bit apps,
they need to be installed in the syswow64 directory, NOT in the system32
directory (note how intuitively obvious it is: 32-bit apps are in syswow64,
and 64-bit apps are in system32; the reason is that incompetent programmers
hard-wired system32 into their apps, and when they recompiled the apps under
the 64-bit compiler they didn't want to be troubled by changing system32 to
system64, so for backward compatibility with badly-written apps [there
always was a GetWindowsSystemDirectory API, but too many programmers
couldn't be troubled to do their job right] they had to put all the 64-bit
stuff in a directory called system32). Note that if your DLL is a 32-bit
DLL, it should NOT be installed in system32, it should be in syswow64, and
if you have a 64-bit DLL, it should be installed in system32. So I can't
figure out why you want to try to load 64-bit DLLs into 32-bit apps. The
idea of the file redirection is to make this transparent to apps; the
penalty is that you have to have a correct 32-bit install setup to make sure
your 32-bit DLL goes into syswow64.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@driverentry.com.br
Sent: Thursday, March 10, 2011 6:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] 32 bit application for 64 bit driver
Hi,
You can disable the Wow64 File System Redirection by using this routine:
BOOL WINAPI Wow64DisableWow64FsRedirection(
__out PVOID *OldValue
);
Fernando Roberto da Silva
DriverEntry Kernel Development
http://www.driverentry.com.br/en
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
It is absolutely inappropriate for an application to provide a kernel address to the driver. An application is in untrusted domain. Passing wrong kernel address will promptly crash the system, or allow memory corruption, which you’d not want. It is a plain security vulnerability.
Change your driver to pass 32-bit “handle” in place of “address”. That will solve your 64 bit compatibility problem, AND close the security vulnerability.