64 bit daemon tools

[ebatsky]

hi, im just curious, why does 64 bit daemon tools driver have to be rewritten completely?

i have a programming background although ive never written drivers and i just did some research on 64 bit drivers vs 32 bit (out of curiousity) and basically theres a microsoft page for transitions and it says something along the lines that api remains the same and biggest problem is that you can no longer cast pointers into ints and back (because pointers are now 64 bit but ints remain 32 bit). there are also a few special new functions that should be checked before ioctl calls but these are basically an 'if' wrapper.

this isnt a request for new versions or anything im simply curious as to why theres such a big difference between 64 and 32 bit drivers, if anyone has time and willingless to reply

[mwb1100]

I can't speak to Daemon Tools specifically, but porting to x64 is a mixed bag - some things are easy, some more complex.

As far as device drivers go, the complexity can come from the fact that a 64-bit driver must be able to handle requests from 64 and 32 bit applications, so the structures that pass addresses around must take into account the different sizes, and the driver may have to do things differently depending on the application type.

On the non-device driver side, things are easier, but there are issues when trying to integrate into the Windows shell, for example (this area I really know next to nothing about).

[Jito463]

Keep in mind that writing drivers for physical hardware is tough enough. But all those drivers are doing is passing commands back and forth between the OS and the hardware. With virtual drive software, it's not just passing commands, it's doing all the work. There's more involved with virtual device drivers than just a few lines of code. Otherwise we would have seen DT4 ages ago.

[Nikos]

i have a programming background although ive never written drivers and i just did some research on 64 bit drivers vs 32 bit (out of curiousity) and basically theres a microsoft page for transitions and it says something along the lines that api remains the same

Drivers don't use the API for the low-level stuff.

and biggest problem is that you can no longer cast pointers into ints and back (because pointers are now 64 bit but ints remain 32 bit).

That's actually wrong. An int is the "natural" word-size of the system. DOS compilers have a 16-bit int. Unices and w32 have 32-bit ints. "Real" 64-bit compilers have 64-bit ints. C and C++ guarantee that an int is at least 16-bit. The standard does not specify an exact value.

And casting pointers to ints (and vice versa) is a case for the code police anyway.

[Kinlaadare]

(...)
And casting pointers to ints (and vice versa) is a case for the code police anyway.

This is in fact a really bad idea...

[ebatsky]

ints i was talking about was windows defined ints, INT32, INT64, etc, which is what is used everywhere in windows api and what you are suppose to be using when writing windows apps (probably drivers also), not the default int (which is usually defined as INT which is defined as INT32 anyways)

as for casting ints/longs to pointers, you have to do this if you wish to test some bits, set or clear bits, etc.

there are now even special functions, in 64 bit api, to do this for you safely, see: http://msdn.microsoft.com/library/de...g_pointers.asp

As far as device drivers go, the complexity can come from the fact that a 64-bit driver must be able to handle requests from 64 and 32 bit applications, so the structures that pass addresses around must take into account the different sizes, and the driver may have to do things differently depending on the application type.

this i suspect is the real problem, however according to ms articles this only really involves putting an if statement around ioctl calls and calling different function versions depending on the app using the driver (32 bit or 64). however im not totally sure about this.

also a virtual device driver isnt much different from a real driver other than instead of getting data from a device, you get it from, say, file. obviously that is more complicated but i have doubts as to whether this would involve more than any regular driver

well, supposedly 64 bit compatible daemon tools is coming out within the next 6 days so i guess we'll see.....