I have an app. I compile it both as a 32 and 64 bit app. All operations are 32 bit. I dont do anything specific to 64 bit. Both these app works with the same 64 bit driver on a Intel 64 bit system. The app is used for dumping the PCIE config space. It makes a request starting from Start Bus to End Bus all devices and functions. It dumps the first 256 bytes. The driver does not have any ULONG_PTR. Everything is forced to 32 bit only.
When I do the dump using the 64 bit app the whole dump is done in some 45 seconds. When I use the 32 bit app it take > 5 minutes. Same system and the driver binary is also the same one. Only difference is one is 32 bit and the other one is 64 bit app. Again the apps are also same source code without any ifdef’s just compiled for 32 and 64 bit types.
Question: Could someone kindly explain why the enormous slowness? Can I blame it on the WOW64 x86 emulator?
http://msdn.microsoft.com/en-us/library/aa384219(v=vs.85).aspx
does tell performance is bad, can it be this bad? Please note this is more a academic curiosity and so I dont want an alternate way to dump the config space basically I want to understand how does a 32 bit app request and a 64 bit app request to the same binary vary so much. Just to clarify the application are not run in parallel. When they run they run all by themselves.
What exactly you mean by Intel 64 bit system? Explain.
Thanks for the quick response. It is a x64 architecture system. The processor is capable of 64 bit operation and WOW64 emulator allows the system to run 32 bit applications too. However the driver has to be 64 bit only. It will reside in SysWOW64\drivers.
On Sun, 23 Jan 2011 14:24:28 -0500 (EST)
xxxxx@gmail.com wrote:
be 64 bit only. It will reside in SysWOW64\drivers.
No it won’t - 64-bit drivers go into system32 and 32-bit drivers into
syswow64.
–
Bruce Cran
>
On Sun, 23 Jan 2011 14:24:28 -0500 (EST)
xxxxx@gmail.com wrote:
> be 64 bit only. It will reside in SysWOW64\drivers.
No it won’t - 64-bit drivers go into system32 and 32-bit drivers into
syswow64.
What sort of 32-bit driver works on a 64-bit system? Does UMDF allow
this?
James
Okay from what I have understood to make a 32 bit driver work on a 64 bit system it is some effort. In my case I use the same driver binary when I use the 32 or 64 bit app. Technically I can keep the driver where ever I want right? Anyway I read up on the Wow64 emulator and feel that might be it. Some more specific info as to what is happening when I spin for a long time.
Normally on a Intel Sever platform 64 bit there is Bus 0 and couple more buses each with couple of devices and functions at the beginning and then at the way end there is the 253, 254 buses with couple of devices and functions.
The delay is seen when the scan is traversing the big gap between the first bunch of buses and the last clump of buses. All I do in my driver is check if Function 0 of a given Device exists if not go to the next device. A 0xFFFFFFFF is an indication of inaccessibly address. I would say I make about 8000 IOCTL calls to the driver in this process. So if the emulator causes a 2 sec delay in each system call then that would addup to approx 5 minutes. Does this sound right?
On Mon, 24 Jan 2011 08:37:04 +1100
“James Harper” wrote:
> What sort of 32-bit driver works on a 64-bit system? Does UMDF allow
> this?
Sorry, I meant dlls not drivers - on Windows x64 all drivers are 64-bit
as far as I know.
–
Bruce Cran
All real kernel mode drivers for Windows must be compiled to match the
bit-ness of the target. You may not install a 32-bit driver on a 64-bit OS
and this was true even for Itanium. I will not address the UMDF issue since
I am not certain though I believe that someone I trust said even that won’t
work.
“James Harper” wrote in message news:xxxxx@ntdev…
On Sun, 23 Jan 2011 14:24:28 -0500 (EST)
xxxxx@gmail.com wrote:
> be 64 bit only. It will reside in SysWOW64\drivers.
No it won’t - 64-bit drivers go into system32 and 32-bit drivers into
syswow64.
What sort of 32-bit driver works on a 64-bit system? Does UMDF allow
this?
James
wrote in message news:xxxxx@ntdev…
…
> The delay is seen when the scan is traversing the big gap between the
> first bunch of buses and the last clump of buses. All I do in my driver is
> check if Function 0 of a given Device exists if not go to the next device.
> A 0xFFFFFFFF is an indication of inaccessibly address. I would say I make
> about 8000 IOCTL calls to the driver in this process. So if the emulator
> causes a 2 sec delay in each system call then that would addup to approx 5
> minutes. Does this sound right?
>
“Emulator causes a 2 sec delay in each system call” is absolutely
unreasonable.
Look for some 32/64 compatibility bug, such as looping from 0 to
FFFFFFFFFFFFFFFF
instead of FFFFFFFF. Which can be something like:
for ( PVOID p = 0, q = -1; p != q; p++)
–pa
Okay sorry I don’t know, yes I was just speculating. Question is how much delay does the emulator insert?
http://msdn.microsoft.com/en-us/library/aa384219(v=vs.85).aspx
The above URL is the only one I could get to read off about emulator. If some one has characterized the actual time that would confirm my doubt.
Might be my issue has very little to do with emulation delay and much to do with something else. Dont know.
32 bit code running on an x64 system does NOT entail any sort of emulator. All that’s really done is thunk the 32 but addresses to 64 bit on entry to the OS. That’s all.
Peter
OSR
Thank you Peter. So it is something else and I will figure it out. I hoped 
and suspected the emulator. One thing out of the way. This case might be closed. Thanks.
> Look for some 32/64 compatibility bug, such as looping from 0 to
FFFFFFFFFFFFFFFF
instead of FFFFFFFF.
Oh yes, really looks like this.
Which can be something like:
for ( PVOID p = 0, q = -1; p != q; p++)
Or more so - promoting LONG to (U)LONGLONG, if LONG is 0xffffffff then the 64bit result will be 0xffffffffffffffff
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com