32 bit app inf file for 64 bit systems

NTDEV
1

hi all,
we write 12 at the defaultdestdir section on the inf file for put the system files to system32\drivers path but if we use a 32 bit app, the system files should be in systemWow64\drivers, am i right? so what can i write at the DefaultDestDir section on the inf file?

Son

2

xxxxx@live.com wrote:

hi all,
we write 12 at the defaultdestdir section on the inf file for put the system files to system32\drivers path but if we use a 32 bit app, the system files should be in systemWow64\drivers, am i right? so what can i write at the DefaultDestDir section on the inf file?

No, you are not right.

Drivers always go in system32\drivers. On a 64-bit system, drivers MUST
be 64-bit, and everything 64-bit goes into system32.

Now, if you have a 32-bit DLL to help your driver, then it would go into
syswow64. There is no syswow64\drivers (if there is one, it was a mistake).

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

no, i have no dll file.
Thanks for asking.

Son

Date: Tue, 12 Apr 2011 09:13:50 -0700
From: xxxxx@probo.com
To: xxxxx@lists.osr.com
Subject: Re: [ntdev] 32 bit app inf file for 64 bit systems

xxxxx@live.com wrote:
> hi all,
> we write 12 at the defaultdestdir section on the inf file for put the system files to system32\drivers path but if we use a 32 bit app, the system files should be in systemWow64\drivers, am i right? so what can i write at the DefaultDestDir section on the inf file?

No, you are not right.

Drivers always go in system32\drivers. On a 64-bit system, drivers MUST
be 64-bit, and everything 64-bit goes into system32.

Now, if you have a 32-bit DLL to help your driver, then it would go into
syswow64. There is no syswow64\drivers (if there is one, it was a mistake).

–
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

4

ilker alici wrote:

no, i have no dll file.
Thanks for asking.

OK, then are you clear about the situation? Your 64-bit driver will
always go in %12% – system32\drivers. A 32-bit application can send
requests to a 64-bit driver just fine. The operating system handles
that transition for you.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

so what? i havent run app yet but i wish it will work, maybe there will be a problem about CreateHandle or stack location (IoGetCurrentIrpStackLocation). anywhere else do you advise?

Son

Date: Tue, 12 Apr 2011 10:15:02 -0700
From: xxxxx@probo.com
To: xxxxx@lists.osr.com
Subject: Re: [ntdev] 32 bit app inf file for 64 bit systems

ilker alici wrote:
> no, i have no dll file.
> Thanks for asking.

OK, then are you clear about the situation? Your 64-bit driver will
always go in %12% – system32\drivers. A 32-bit application can send
requests to a 64-bit driver just fine. The operating system handles
that transition for you.

–
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

6

ilker alici wrote:

so what? i havent run app yet but i wish it will work, maybe there
will be a problem about CreateHandle or stack location
(IoGetCurrentIrpStackLocation). anywhere else do you advise?

Well, you’re talking about two different situations here. Within the
kernel, everything is 64 bits. As long as you have not done anything
silly (like store virtual addresses in “unsigned long” variables),
porting a driver to 64 bits often takes nothing more than recompiling.
(You will need two separate binaries – one for 32 bit systems, one for
64 bit systems, and you will need to digitally sign your 64-bit
binary.) You don’t have to worry about kernel APIs.

Things get a little trickier when we talk about calling the driver from
an application. Here, the potential for trouble depends on what you are
passing to the driver. The buffers in the IRP will all work the same,
but if the buffer you are passing contains user-mode pointers, then you
have a problem, because pointers are a different size. For example,
let’s say I have an ioctl where the buffer I pass includes a “void *”.
In my 32-bit application, that’s 4 bytes, but the driver will expect 8
bytes. Further, I can call the driver from either a 32-bit application
or a 64-bit application, where the input buffer changes size.

There are two ways to handle that. You can create separate ioctl codes
for 32-bit and 64-bit apps, with natively sized structures. Or, the
driver can check whether the calling application was 32-bit or 64-bit,
and convert the data structures where necessary.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

All the 32bit app - 64bit driver issues aside, if you try to install your
driver from a 32bit application on a 64 bit system you might need to disable
WOW64 redirection (see the MSDN page for Wow64DisableWow64FsRedirection
currently at http://msdn.microsoft.com/en-us/library/aa365743(v=vs.85).aspx;
also don’t forget to revert it (Wow64RevertWow64FsRedirection) after
installing the driver).

Thanks,
Alex.

8

You RIGHT;
there is void * parameters you said as ;
BOOL read_pci_config_space(HANDLE hDevice, void *output_buffer, unsigned long output_buffer_size, unsigned long *bytes_returned)
or
void *shared_memory_addr; // pointer to shared memory
i should change them!!

and you talked about two ways to handle, is there any documantation about how can i do this?

Son

Date: Tue, 12 Apr 2011 10:51:12 -0700
From: xxxxx@probo.com
To: xxxxx@lists.osr.com
Subject: Re: [ntdev] 32 bit app inf file for 64 bit systems

ilker alici wrote:
> so what? i havent run app yet but i wish it will work, maybe there
> will be a problem about CreateHandle or stack location
> (IoGetCurrentIrpStackLocation). anywhere else do you advise?

Well, you’re talking about two different situations here. Within the
kernel, everything is 64 bits. As long as you have not done anything
silly (like store virtual addresses in “unsigned long” variables),
porting a driver to 64 bits often takes nothing more than recompiling.
(You will need two separate binaries – one for 32 bit systems, one for
64 bit systems, and you will need to digitally sign your 64-bit
binary.) You don’t have to worry about kernel APIs.

Things get a little trickier when we talk about calling the driver from
an application. Here, the potential for trouble depends on what you are
passing to the driver. The buffers in the IRP will all work the same,
but if the buffer you are passing contains user-mode pointers, then you
have a problem, because pointers are a different size. For example,
let’s say I have an ioctl where the buffer I pass includes a “void *”.
In my 32-bit application, that’s 4 bytes, but the driver will expect 8
bytes. Further, I can call the driver from either a 32-bit application
or a 64-bit application, where the input buffer changes size.

There are two ways to handle that. You can create separate ioctl codes
for 32-bit and 64-bit apps, with natively sized structures. Or, the
driver can check whether the calling application was 32-bit or 64-bit,
and convert the data structures where necessary.

–
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

9

ilker alici wrote:

You RIGHT;
there is void * parameters you said as ;
BOOL read_pci_config_space(HANDLE hDevice, *void *output_buffer*,
unsigned long output_buffer_size, unsigned long *bytes_returned)
or
void *shared_memory_addr; // pointer to shared memory
i should change them!!

Not necessarily. For example, I’m guessing that first call eventually
turns into:
DeviceIoControl( hDevice,
IOCTL_READ_MY_PCI_SPACE,
NULL, 0,
output_buffer, output_buffer_size,
bytes_returned,
NULL
);

That doesn’t need any changes at all. The I/O manager will handle the
addresses, so that the IRP contains a 64-bit pointer into the 32-bit
process.

The TROUBLE happens when the buffer itself contains a pointer. For
example, if that “shared_memory_addr” is returned to you in the output
buffer of an ioctl, then you have a problem. This is one reason why
shared memory is so often a bad answer.

and you talked about two ways to handle, is there any documantation
about how can i do this?

I described the two methods. The key is remembering that “void *” has a
different size in a 32-bit module and a 64-bit module. The first method
is to have two separate ioctls, like IOCTL_MY_GET_SHARED_MEMORY_32
(which return 4 bytes) and IOCTL_MY_GET_SHARED_MEMORY_64 (which returns
8 bytes). The second method is to keep one ioctl code, but use
IoIs32bitProcess within the driver to decide what to do. That may be
the better solution, because you don’t have to modify the application –
your existing application binaries will still work.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

10

You said;

The TROUBLE happens when the buffer itself contains a pointer. For
example, if that “shared_memory_addr” is returned to you in the output
buffer of an ioctl, then you have a problem. This is one reason why
shared memory is so often a bad answer.
like this;

BOOL create_process_shared_memory(struct my_driver_handle_structure_s *hDevice, unsigned short *fail_reason)
{
BOOL fInit;
USHORT i;

hDevice->driver_process_ram.driver_map_object_handle = CreateFileMapping(
INVALID_HANDLE_VALUE, // use paging file
NULL, // default security attributes
PAGE_READWRITE, // read/write access
0, // size: high 32-bits
SHMEMSIZE, // size: low 32-bits
“MySharedMem”); // name of map object

I think IoIs32bitProcess is better too.

Son

Date: Tue, 12 Apr 2011 11:40:06 -0700
From: xxxxx@probo.com
To: xxxxx@lists.osr.com
Subject: Re: [ntdev] 32 bit app inf file for 64 bit systems

ilker alici wrote:
>
> You RIGHT;
> there is void * parameters you said as ;
> BOOL read_pci_config_space(HANDLE hDevice, *void *output_buffer*,
> unsigned long output_buffer_size, unsigned long *bytes_returned)
> or
> void *shared_memory_addr; // pointer to shared memory
> i should change them!!

Not necessarily. For example, I’m guessing that first call eventually
turns into:
DeviceIoControl( hDevice,
IOCTL_READ_MY_PCI_SPACE,
NULL, 0,
output_buffer, output_buffer_size,
bytes_returned,
NULL
);

That doesn’t need any changes at all. The I/O manager will handle the
addresses, so that the IRP contains a 64-bit pointer into the 32-bit
process.

The TROUBLE happens when the buffer itself contains a pointer. For
example, if that “shared_memory_addr” is returned to you in the output
buffer of an ioctl, then you have a problem. This is one reason why
shared memory is so often a bad answer.

> and you talked about two ways to handle, is there any documantation
> about how can i do this?

I described the two methods. The key is remembering that “void *” has a
different size in a 32-bit module and a 64-bit module. The first method
is to have two separate ioctls, like IOCTL_MY_GET_SHARED_MEMORY_32
(which return 4 bytes) and IOCTL_MY_GET_SHARED_MEMORY_64 (which returns
8 bytes). The second method is to keep one ioctl code, but use
IoIs32bitProcess within the driver to decide what to do. That may be
the better solution, because you don’t have to modify the application –
your existing application binaries will still work.

–
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

11

ilker alici wrote:

like this;

BOOL create_process_shared_memory(struct my_driver_handle_structure_s
*hDevice, unsigned short *fail_reason)
{
BOOL fInit;
USHORT i;

hDevice->driver_process_ram.driver_map_object_handle =
CreateFileMapping(
INVALID_HANDLE_VALUE, // use paging file
NULL, &nb sp; // default
security attributes
PAGE_READWRITE, // read/write access
0, // size: high 32-bits
SHMEMSIZE, // size: low 32-bits
“MySharedMem”); / / name of map object

This is perfectly fine – no changes needed. You aren’t communicating
with the driver here – you are just using a standard Win32 API.

The only things you really need to focus on are DeviceIoControl calls
directly into the driver where you are passing an array.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

12

Tim Roberts wrote:

…
The only things you really need to focus on are DeviceIoControl calls
directly into the driver where you are passing an array.

Whoops, make that last word “address”. Too many things going on today.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

ok, i see. i should busy with this addresses which DeviceIoControl calls. so you mean this parameters;

/*the user mode I/O Request is encoded by reading from the current IRP’s stack*/

ULONG inBufLen = stack->Parameters.DeviceIoControl.InputBufferLength;
ULONG outBufLen = stack->Parameters.DeviceIoControl.OutputBufferLength;

thanks

Son

Date: Tue, 12 Apr 2011 14:18:18 -0700
From: xxxxx@probo.com
To: xxxxx@lists.osr.com
Subject: Re: [ntdev] 32 bit app inf file for 64 bit systems

ilker alici wrote:
>
> like this;
>
> BOOL create_process_shared_memory(struct my_driver_handle_structure_s
> *hDevice, unsigned short *fail_reason)
> {
> BOOL fInit;
> USHORT i;
>
>
> hDevice->driver_process_ram.driver_map_object_handle =
> CreateFileMapping(
> INVALID_HANDLE_VALUE, // use paging file
> NULL, &nb sp; // default
> security attributes
> PAGE_READWRITE, // read/write access
> 0, // size: high 32-bits
> SHMEMSIZE, // size: low 32-bits
> “MySharedMem”); / / name of map object

This is perfectly fine – no changes needed. You aren’t communicating
with the driver here – you are just using a standard Win32 API.

The only things you really need to focus on are DeviceIoControl calls
directly into the driver where you are passing an array.

–
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

14

ilker alici wrote:

ok, i see. i should busy with this addresses which DeviceIoControl
calls. so you mean this parameters;

/*the user mode I/O Request is encoded by reading from the current
IRP’s stack*/

ULONG *inBufLen *=
stack->Parameters.DeviceIoControl.InputBufferLength;
ULONG *outBufLen *=
stack->Parameters.DeviceIoControl.OutputBufferLength;

No. The fields in the IRP are all handled for you. Any issues are
going to be with the data passed in Irp->AssociatedIrp.SystemBuffer or
Irp->MdlAddress. Since the content of those buffers is strictly defined
by YOU, the operating system cannot know what’s inside of them. It
might be that you have no problem at all – it just depends on what data
you are passing in those buffers.

If you want to send me the source code for your driver by private email,
I can give it a quick look and tell you if there are any likely trouble
spots.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.