Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Windows 64bit > What's the difference between drivers and applications

Reply
Thread Tools

What's the difference between drivers and applications

 
 
=?Utf-8?B?Ym9i?=
Guest
Posts: n/a
 
      07-02-2005
I am able to run 32-bit applications on my 64-bit operating system, so
presumably there's a translator sitting inbetween the application and the OS
that converts the bits to the appropriate length.

Why can't this be done with the drivers? It doesn't need to negate the need
for real 64-bit drivers, but something, anything, even with limited speed or
functionality is better than nothing which is what I have now.

<vent>
Not counting my motherboard drivers, currently I only have only 1 64-bit
driver (video card) available to me for all of my hardware and peripherals. I
upgraded to x64 because I was told it take full advantage of my processor and
be twice as fast, this has not been the case. I've not noticed any gains in
using x64, only limitations.

I've hung in for quite a while now hoping that drivers would be available,
but I've now lost all hope. I can't think of a reason that anyone would use
x64 other than to post here and keep Microsoft informed of what hardware they
have that doesn't work.

So please, Microsoft, give us something that will make our 32-bit drivers
work or tell Intel and AMD to stop making 64-bit processors because there's
not a functioning operating system available that supports them.
</vent>
 
Reply With Quote
 
 
 
 
Jerry
Guest
Posts: n/a
 
      07-02-2005
You are venting in the wrong place. Drivers are the responsibility of the
hardware manufacturers, not Microsoft or Intel.

"bob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I am able to run 32-bit applications on my 64-bit operating system, so
> presumably there's a translator sitting inbetween the application and the
> OS
> that converts the bits to the appropriate length.
>
> Why can't this be done with the drivers? It doesn't need to negate the
> need
> for real 64-bit drivers, but something, anything, even with limited speed
> or
> functionality is better than nothing which is what I have now.
>
> <vent>
> Not counting my motherboard drivers, currently I only have only 1 64-bit
> driver (video card) available to me for all of my hardware and
> peripherals. I
> upgraded to x64 because I was told it take full advantage of my processor
> and
> be twice as fast, this has not been the case. I've not noticed any gains
> in
> using x64, only limitations.
>
> I've hung in for quite a while now hoping that drivers would be available,
> but I've now lost all hope. I can't think of a reason that anyone would
> use
> x64 other than to post here and keep Microsoft informed of what hardware
> they
> have that doesn't work.
>
> So please, Microsoft, give us something that will make our 32-bit drivers
> work or tell Intel and AMD to stop making 64-bit processors because
> there's
> not a functioning operating system available that supports them.
> </vent>



 
Reply With Quote
 
 
 
 
Andre Da Costa [Extended64]
Guest
Posts: n/a
 
      07-02-2005
A driver is the counselor between your hardware and operating system and
allows both communicate with each other and function together. Applications
are different because it is software based which is used for general
specialized purposes.

What you seem to be confusing is 32 bit installer for an application on
Windows XP Professional x64 and 32 bit device driver for hardware. The thing
with 32 bit hardware and 64 bit, they just don't communicate because of
specific system level requirements to function.

WOW64
At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its
initialization code, which loads all necessary 32-bit DLLs. Nearly all
32-bit DLLs are unmodified copies of 32-bit Windows XP binaries. However,
some of these DLLs have knowledge of WOW64, usually because they share
memory with 64-bit processes.

Instead of using the x86 system-service call sequence; 32-bit binaries
making system calls are rebuilt to use a custom calling sequence. This new
sequence is inexpensive for WOW64 to intercept because it remains entirely
in user mode. When the new calling sequence is detected, the WOW64 CPU
transitions back to native 64-bit mode and calls into (Wow64.dll). Thunking
is done in user mode to reduce the impact on the 64-bit kernel, and to
reduce the risk of a bug in the thunk causing a kernel-mode crash, data
corruption, or a security hole. The thunks extract arguments from the 32-bit
stack, extend them to 64 bits, and then make the native system call.

WOW64 enables 32-bit applications to take advantage of the 64-bit kernel.
Therefore, 32-bit applications can use a larger number of kernel handles and
window handles. However, 32-bit applications cannot create as many threads
under WOW64 as they can on x86, because there is less virtual address space
available, and each thread contains a 64-bit stack (usually 512K).

Now you should understand why 32 bit applications are able to run on 64 bit
Windows.
--
Andre
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta
FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm

"bob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I am able to run 32-bit applications on my 64-bit operating system, so
> presumably there's a translator sitting inbetween the application and the
> OS
> that converts the bits to the appropriate length.
>
> Why can't this be done with the drivers? It doesn't need to negate the
> need
> for real 64-bit drivers, but something, anything, even with limited speed
> or
> functionality is better than nothing which is what I have now.
>
> <vent>
> Not counting my motherboard drivers, currently I only have only 1 64-bit
> driver (video card) available to me for all of my hardware and
> peripherals. I
> upgraded to x64 because I was told it take full advantage of my processor
> and
> be twice as fast, this has not been the case. I've not noticed any gains
> in
> using x64, only limitations.
>
> I've hung in for quite a while now hoping that drivers would be available,
> but I've now lost all hope. I can't think of a reason that anyone would
> use
> x64 other than to post here and keep Microsoft informed of what hardware
> they
> have that doesn't work.
>
> So please, Microsoft, give us something that will make our 32-bit drivers
> work or tell Intel and AMD to stop making 64-bit processors because
> there's
> not a functioning operating system available that supports them.
> </vent>



 
Reply With Quote
 
=?Utf-8?B?Ym9i?=
Guest
Posts: n/a
 
      07-02-2005
Thank you for your baffling paste.

Could you clarify.. Were you saying it was impossible to have an application
that translated 32-bit drivers? Or just that currently one doesn't exist?

For example, if I ran vmware's pc emulator on x64, would I finally be able
to print with my 32-bit drivers?

And if so, could it not be possible to create a mini version of that
application that just dealt with translating drivers?

"Andre Da Costa [Extended64]" wrote:

> A driver is the counselor between your hardware and operating system and
> allows both communicate with each other and function together. Applications
> are different because it is software based which is used for general
> specialized purposes.
>
> What you seem to be confusing is 32 bit installer for an application on
> Windows XP Professional x64 and 32 bit device driver for hardware. The thing
> with 32 bit hardware and 64 bit, they just don't communicate because of
> specific system level requirements to function.
>
> WOW64
> At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its
> initialization code, which loads all necessary 32-bit DLLs. Nearly all
> 32-bit DLLs are unmodified copies of 32-bit Windows XP binaries. However,
> some of these DLLs have knowledge of WOW64, usually because they share
> memory with 64-bit processes.
>
> Instead of using the x86 system-service call sequence; 32-bit binaries
> making system calls are rebuilt to use a custom calling sequence. This new
> sequence is inexpensive for WOW64 to intercept because it remains entirely
> in user mode. When the new calling sequence is detected, the WOW64 CPU
> transitions back to native 64-bit mode and calls into (Wow64.dll). Thunking
> is done in user mode to reduce the impact on the 64-bit kernel, and to
> reduce the risk of a bug in the thunk causing a kernel-mode crash, data
> corruption, or a security hole. The thunks extract arguments from the 32-bit
> stack, extend them to 64 bits, and then make the native system call.
>
> WOW64 enables 32-bit applications to take advantage of the 64-bit kernel.
> Therefore, 32-bit applications can use a larger number of kernel handles and
> window handles. However, 32-bit applications cannot create as many threads
> under WOW64 as they can on x86, because there is less virtual address space
> available, and each thread contains a 64-bit stack (usually 512K).
>
> Now you should understand why 32 bit applications are able to run on 64 bit
> Windows.
> --
> Andre
> Extended64 | http://www.extended64.com
> Blog | http://www.extended64.com/blogs/andre
> http://spaces.msn.com/members/adacosta
> FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
>
> "bob" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >I am able to run 32-bit applications on my 64-bit operating system, so
> > presumably there's a translator sitting inbetween the application and the
> > OS
> > that converts the bits to the appropriate length.
> >
> > Why can't this be done with the drivers? It doesn't need to negate the
> > need
> > for real 64-bit drivers, but something, anything, even with limited speed
> > or
> > functionality is better than nothing which is what I have now.
> >
> > <vent>
> > Not counting my motherboard drivers, currently I only have only 1 64-bit
> > driver (video card) available to me for all of my hardware and
> > peripherals. I
> > upgraded to x64 because I was told it take full advantage of my processor
> > and
> > be twice as fast, this has not been the case. I've not noticed any gains
> > in
> > using x64, only limitations.
> >
> > I've hung in for quite a while now hoping that drivers would be available,
> > but I've now lost all hope. I can't think of a reason that anyone would
> > use
> > x64 other than to post here and keep Microsoft informed of what hardware
> > they
> > have that doesn't work.
> >
> > So please, Microsoft, give us something that will make our 32-bit drivers
> > work or tell Intel and AMD to stop making 64-bit processors because
> > there's
> > not a functioning operating system available that supports them.
> > </vent>

>
>
>

 
Reply With Quote
 
Andre Da Costa [Extended64]
Guest
Posts: n/a
 
      07-02-2005
Emulation software I believe goes much deeper, to the point where it
virtualizes the processor which I believe requires it to be written natively
to do such a task.
--
Andre
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta
FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm

"bob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thank you for your baffling paste.
>
> Could you clarify.. Were you saying it was impossible to have an
> application
> that translated 32-bit drivers? Or just that currently one doesn't exist?
>
> For example, if I ran vmware's pc emulator on x64, would I finally be able
> to print with my 32-bit drivers?
>
> And if so, could it not be possible to create a mini version of that
> application that just dealt with translating drivers?
>
> "Andre Da Costa [Extended64]" wrote:
>
>> A driver is the counselor between your hardware and operating system and
>> allows both communicate with each other and function together.
>> Applications
>> are different because it is software based which is used for general
>> specialized purposes.
>>
>> What you seem to be confusing is 32 bit installer for an application on
>> Windows XP Professional x64 and 32 bit device driver for hardware. The
>> thing
>> with 32 bit hardware and 64 bit, they just don't communicate because of
>> specific system level requirements to function.
>>
>> WOW64
>> At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its
>> initialization code, which loads all necessary 32-bit DLLs. Nearly all
>> 32-bit DLLs are unmodified copies of 32-bit Windows XP binaries. However,
>> some of these DLLs have knowledge of WOW64, usually because they share
>> memory with 64-bit processes.
>>
>> Instead of using the x86 system-service call sequence; 32-bit binaries
>> making system calls are rebuilt to use a custom calling sequence. This
>> new
>> sequence is inexpensive for WOW64 to intercept because it remains
>> entirely
>> in user mode. When the new calling sequence is detected, the WOW64 CPU
>> transitions back to native 64-bit mode and calls into (Wow64.dll).
>> Thunking
>> is done in user mode to reduce the impact on the 64-bit kernel, and to
>> reduce the risk of a bug in the thunk causing a kernel-mode crash, data
>> corruption, or a security hole. The thunks extract arguments from the
>> 32-bit
>> stack, extend them to 64 bits, and then make the native system call.
>>
>> WOW64 enables 32-bit applications to take advantage of the 64-bit kernel.
>> Therefore, 32-bit applications can use a larger number of kernel handles
>> and
>> window handles. However, 32-bit applications cannot create as many
>> threads
>> under WOW64 as they can on x86, because there is less virtual address
>> space
>> available, and each thread contains a 64-bit stack (usually 512K).
>>
>> Now you should understand why 32 bit applications are able to run on 64
>> bit
>> Windows.
>> --
>> Andre
>> Extended64 | http://www.extended64.com
>> Blog | http://www.extended64.com/blogs/andre
>> http://spaces.msn.com/members/adacosta
>> FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
>>
>> "bob" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> >I am able to run 32-bit applications on my 64-bit operating system, so
>> > presumably there's a translator sitting inbetween the application and
>> > the
>> > OS
>> > that converts the bits to the appropriate length.
>> >
>> > Why can't this be done with the drivers? It doesn't need to negate the
>> > need
>> > for real 64-bit drivers, but something, anything, even with limited
>> > speed
>> > or
>> > functionality is better than nothing which is what I have now.
>> >
>> > <vent>
>> > Not counting my motherboard drivers, currently I only have only 1
>> > 64-bit
>> > driver (video card) available to me for all of my hardware and
>> > peripherals. I
>> > upgraded to x64 because I was told it take full advantage of my
>> > processor
>> > and
>> > be twice as fast, this has not been the case. I've not noticed any
>> > gains
>> > in
>> > using x64, only limitations.
>> >
>> > I've hung in for quite a while now hoping that drivers would be
>> > available,
>> > but I've now lost all hope. I can't think of a reason that anyone
>> > would
>> > use
>> > x64 other than to post here and keep Microsoft informed of what
>> > hardware
>> > they
>> > have that doesn't work.
>> >
>> > So please, Microsoft, give us something that will make our 32-bit
>> > drivers
>> > work or tell Intel and AMD to stop making 64-bit processors because
>> > there's
>> > not a functioning operating system available that supports them.
>> > </vent>

>>
>>
>>



 
Reply With Quote
 
Andre Da Costa [Extended64]
Guest
Posts: n/a
 
      07-02-2005
Colin would be more suitable to answer such a question.
--
Andre
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta
FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm

"bob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thank you for your baffling paste.
>
> Could you clarify.. Were you saying it was impossible to have an
> application
> that translated 32-bit drivers? Or just that currently one doesn't exist?
>
> For example, if I ran vmware's pc emulator on x64, would I finally be able
> to print with my 32-bit drivers?
>
> And if so, could it not be possible to create a mini version of that
> application that just dealt with translating drivers?
>
> "Andre Da Costa [Extended64]" wrote:
>
>> A driver is the counselor between your hardware and operating system and
>> allows both communicate with each other and function together.
>> Applications
>> are different because it is software based which is used for general
>> specialized purposes.
>>
>> What you seem to be confusing is 32 bit installer for an application on
>> Windows XP Professional x64 and 32 bit device driver for hardware. The
>> thing
>> with 32 bit hardware and 64 bit, they just don't communicate because of
>> specific system level requirements to function.
>>
>> WOW64
>> At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its
>> initialization code, which loads all necessary 32-bit DLLs. Nearly all
>> 32-bit DLLs are unmodified copies of 32-bit Windows XP binaries. However,
>> some of these DLLs have knowledge of WOW64, usually because they share
>> memory with 64-bit processes.
>>
>> Instead of using the x86 system-service call sequence; 32-bit binaries
>> making system calls are rebuilt to use a custom calling sequence. This
>> new
>> sequence is inexpensive for WOW64 to intercept because it remains
>> entirely
>> in user mode. When the new calling sequence is detected, the WOW64 CPU
>> transitions back to native 64-bit mode and calls into (Wow64.dll).
>> Thunking
>> is done in user mode to reduce the impact on the 64-bit kernel, and to
>> reduce the risk of a bug in the thunk causing a kernel-mode crash, data
>> corruption, or a security hole. The thunks extract arguments from the
>> 32-bit
>> stack, extend them to 64 bits, and then make the native system call.
>>
>> WOW64 enables 32-bit applications to take advantage of the 64-bit kernel.
>> Therefore, 32-bit applications can use a larger number of kernel handles
>> and
>> window handles. However, 32-bit applications cannot create as many
>> threads
>> under WOW64 as they can on x86, because there is less virtual address
>> space
>> available, and each thread contains a 64-bit stack (usually 512K).
>>
>> Now you should understand why 32 bit applications are able to run on 64
>> bit
>> Windows.
>> --
>> Andre
>> Extended64 | http://www.extended64.com
>> Blog | http://www.extended64.com/blogs/andre
>> http://spaces.msn.com/members/adacosta
>> FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
>>
>> "bob" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> >I am able to run 32-bit applications on my 64-bit operating system, so
>> > presumably there's a translator sitting inbetween the application and
>> > the
>> > OS
>> > that converts the bits to the appropriate length.
>> >
>> > Why can't this be done with the drivers? It doesn't need to negate the
>> > need
>> > for real 64-bit drivers, but something, anything, even with limited
>> > speed
>> > or
>> > functionality is better than nothing which is what I have now.
>> >
>> > <vent>
>> > Not counting my motherboard drivers, currently I only have only 1
>> > 64-bit
>> > driver (video card) available to me for all of my hardware and
>> > peripherals. I
>> > upgraded to x64 because I was told it take full advantage of my
>> > processor
>> > and
>> > be twice as fast, this has not been the case. I've not noticed any
>> > gains
>> > in
>> > using x64, only limitations.
>> >
>> > I've hung in for quite a while now hoping that drivers would be
>> > available,
>> > but I've now lost all hope. I can't think of a reason that anyone
>> > would
>> > use
>> > x64 other than to post here and keep Microsoft informed of what
>> > hardware
>> > they
>> > have that doesn't work.
>> >
>> > So please, Microsoft, give us something that will make our 32-bit
>> > drivers
>> > work or tell Intel and AMD to stop making 64-bit processors because
>> > there's
>> > not a functioning operating system available that supports them.
>> > </vent>

>>
>>
>>



 
Reply With Quote
 
WM
Guest
Posts: n/a
 
      07-02-2005
It is impossible to have an application that translates 32-bit drivers - it
is not architecturally possible with Windows. There is no way to shim 32-bit
drivers to work. You MUST obtain 64-bit drivers from your device vendor(s)
to be able to use any devices.


"bob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thank you for your baffling paste.
>
> Could you clarify.. Were you saying it was impossible to have an
> application
> that translated 32-bit drivers? Or just that currently one doesn't exist?
>
> For example, if I ran vmware's pc emulator on x64, would I finally be able
> to print with my 32-bit drivers?
>
> And if so, could it not be possible to create a mini version of that
> application that just dealt with translating drivers?
>
> "Andre Da Costa [Extended64]" wrote:
>
>> A driver is the counselor between your hardware and operating system and
>> allows both communicate with each other and function together.
>> Applications
>> are different because it is software based which is used for general
>> specialized purposes.
>>
>> What you seem to be confusing is 32 bit installer for an application on
>> Windows XP Professional x64 and 32 bit device driver for hardware. The
>> thing
>> with 32 bit hardware and 64 bit, they just don't communicate because of
>> specific system level requirements to function.
>>
>> WOW64
>> At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its
>> initialization code, which loads all necessary 32-bit DLLs. Nearly all
>> 32-bit DLLs are unmodified copies of 32-bit Windows XP binaries. However,
>> some of these DLLs have knowledge of WOW64, usually because they share
>> memory with 64-bit processes.
>>
>> Instead of using the x86 system-service call sequence; 32-bit binaries
>> making system calls are rebuilt to use a custom calling sequence. This
>> new
>> sequence is inexpensive for WOW64 to intercept because it remains
>> entirely
>> in user mode. When the new calling sequence is detected, the WOW64 CPU
>> transitions back to native 64-bit mode and calls into (Wow64.dll).
>> Thunking
>> is done in user mode to reduce the impact on the 64-bit kernel, and to
>> reduce the risk of a bug in the thunk causing a kernel-mode crash, data
>> corruption, or a security hole. The thunks extract arguments from the
>> 32-bit
>> stack, extend them to 64 bits, and then make the native system call.
>>
>> WOW64 enables 32-bit applications to take advantage of the 64-bit kernel.
>> Therefore, 32-bit applications can use a larger number of kernel handles
>> and
>> window handles. However, 32-bit applications cannot create as many
>> threads
>> under WOW64 as they can on x86, because there is less virtual address
>> space
>> available, and each thread contains a 64-bit stack (usually 512K).
>>
>> Now you should understand why 32 bit applications are able to run on 64
>> bit
>> Windows.
>> --
>> Andre
>> Extended64 | http://www.extended64.com
>> Blog | http://www.extended64.com/blogs/andre
>> http://spaces.msn.com/members/adacosta
>> FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
>>
>> "bob" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> >I am able to run 32-bit applications on my 64-bit operating system, so
>> > presumably there's a translator sitting inbetween the application and
>> > the
>> > OS
>> > that converts the bits to the appropriate length.
>> >
>> > Why can't this be done with the drivers? It doesn't need to negate the
>> > need
>> > for real 64-bit drivers, but something, anything, even with limited
>> > speed
>> > or
>> > functionality is better than nothing which is what I have now.
>> >
>> > <vent>
>> > Not counting my motherboard drivers, currently I only have only 1
>> > 64-bit
>> > driver (video card) available to me for all of my hardware and
>> > peripherals. I
>> > upgraded to x64 because I was told it take full advantage of my
>> > processor
>> > and
>> > be twice as fast, this has not been the case. I've not noticed any
>> > gains
>> > in
>> > using x64, only limitations.
>> >
>> > I've hung in for quite a while now hoping that drivers would be
>> > available,
>> > but I've now lost all hope. I can't think of a reason that anyone
>> > would
>> > use
>> > x64 other than to post here and keep Microsoft informed of what
>> > hardware
>> > they
>> > have that doesn't work.
>> >
>> > So please, Microsoft, give us something that will make our 32-bit
>> > drivers
>> > work or tell Intel and AMD to stop making 64-bit processors because
>> > there's
>> > not a functioning operating system available that supports them.
>> > </vent>

>>
>>
>>



 
Reply With Quote
 
Andre Da Costa [Extended64]
Guest
Posts: n/a
 
      07-02-2005
Unless Microsoft creates fat binaries like Apple is with OS X.
--
Andre
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta
FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm

"WM" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> It is impossible to have an application that translates 32-bit drivers -
> it is not architecturally possible with Windows. There is no way to shim
> 32-bit drivers to work. You MUST obtain 64-bit drivers from your device
> vendor(s) to be able to use any devices.
>
>
> "bob" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Thank you for your baffling paste.
>>
>> Could you clarify.. Were you saying it was impossible to have an
>> application
>> that translated 32-bit drivers? Or just that currently one doesn't exist?
>>
>> For example, if I ran vmware's pc emulator on x64, would I finally be
>> able
>> to print with my 32-bit drivers?
>>
>> And if so, could it not be possible to create a mini version of that
>> application that just dealt with translating drivers?
>>
>> "Andre Da Costa [Extended64]" wrote:
>>
>>> A driver is the counselor between your hardware and operating system and
>>> allows both communicate with each other and function together.
>>> Applications
>>> are different because it is software based which is used for general
>>> specialized purposes.
>>>
>>> What you seem to be confusing is 32 bit installer for an application on
>>> Windows XP Professional x64 and 32 bit device driver for hardware. The
>>> thing
>>> with 32 bit hardware and 64 bit, they just don't communicate because of
>>> specific system level requirements to function.
>>>
>>> WOW64
>>> At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its
>>> initialization code, which loads all necessary 32-bit DLLs. Nearly all
>>> 32-bit DLLs are unmodified copies of 32-bit Windows XP binaries.
>>> However,
>>> some of these DLLs have knowledge of WOW64, usually because they share
>>> memory with 64-bit processes.
>>>
>>> Instead of using the x86 system-service call sequence; 32-bit binaries
>>> making system calls are rebuilt to use a custom calling sequence. This
>>> new
>>> sequence is inexpensive for WOW64 to intercept because it remains
>>> entirely
>>> in user mode. When the new calling sequence is detected, the WOW64 CPU
>>> transitions back to native 64-bit mode and calls into (Wow64.dll).
>>> Thunking
>>> is done in user mode to reduce the impact on the 64-bit kernel, and to
>>> reduce the risk of a bug in the thunk causing a kernel-mode crash, data
>>> corruption, or a security hole. The thunks extract arguments from the
>>> 32-bit
>>> stack, extend them to 64 bits, and then make the native system call.
>>>
>>> WOW64 enables 32-bit applications to take advantage of the 64-bit
>>> kernel.
>>> Therefore, 32-bit applications can use a larger number of kernel handles
>>> and
>>> window handles. However, 32-bit applications cannot create as many
>>> threads
>>> under WOW64 as they can on x86, because there is less virtual address
>>> space
>>> available, and each thread contains a 64-bit stack (usually 512K).
>>>
>>> Now you should understand why 32 bit applications are able to run on 64
>>> bit
>>> Windows.
>>> --
>>> Andre
>>> Extended64 | http://www.extended64.com
>>> Blog | http://www.extended64.com/blogs/andre
>>> http://spaces.msn.com/members/adacosta
>>> FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
>>>
>>> "bob" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>> >I am able to run 32-bit applications on my 64-bit operating system, so
>>> > presumably there's a translator sitting inbetween the application and
>>> > the
>>> > OS
>>> > that converts the bits to the appropriate length.
>>> >
>>> > Why can't this be done with the drivers? It doesn't need to negate the
>>> > need
>>> > for real 64-bit drivers, but something, anything, even with limited
>>> > speed
>>> > or
>>> > functionality is better than nothing which is what I have now.
>>> >
>>> > <vent>
>>> > Not counting my motherboard drivers, currently I only have only 1
>>> > 64-bit
>>> > driver (video card) available to me for all of my hardware and
>>> > peripherals. I
>>> > upgraded to x64 because I was told it take full advantage of my
>>> > processor
>>> > and
>>> > be twice as fast, this has not been the case. I've not noticed any
>>> > gains
>>> > in
>>> > using x64, only limitations.
>>> >
>>> > I've hung in for quite a while now hoping that drivers would be
>>> > available,
>>> > but I've now lost all hope. I can't think of a reason that anyone
>>> > would
>>> > use
>>> > x64 other than to post here and keep Microsoft informed of what
>>> > hardware
>>> > they
>>> > have that doesn't work.
>>> >
>>> > So please, Microsoft, give us something that will make our 32-bit
>>> > drivers
>>> > work or tell Intel and AMD to stop making 64-bit processors because
>>> > there's
>>> > not a functioning operating system available that supports them.
>>> > </vent>
>>>
>>>
>>>

>
>



 
Reply With Quote
 
Colin Barnhorst
Guest
Posts: n/a
 
      07-02-2005
If it is a usb printer then vmware's usb support would enable you to use the
printer from within the guest. That is a reasonable work-around for your
issue. However, unless you already own vmware and a copy of XP 32-bit not
currently installed elsewhere, you would save money replacing the printer
with one certified for x64.

--
Colin Barnhorst [MVP Windows - Virtual Machine]
(Reply to the group only unless otherwise requested)
"bob" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thank you for your baffling paste.
>
> Could you clarify.. Were you saying it was impossible to have an
> application
> that translated 32-bit drivers? Or just that currently one doesn't exist?
>
> For example, if I ran vmware's pc emulator on x64, would I finally be able
> to print with my 32-bit drivers?
>
> And if so, could it not be possible to create a mini version of that
> application that just dealt with translating drivers?
>
> "Andre Da Costa [Extended64]" wrote:
>
>> A driver is the counselor between your hardware and operating system and
>> allows both communicate with each other and function together.
>> Applications
>> are different because it is software based which is used for general
>> specialized purposes.
>>
>> What you seem to be confusing is 32 bit installer for an application on
>> Windows XP Professional x64 and 32 bit device driver for hardware. The
>> thing
>> with 32 bit hardware and 64 bit, they just don't communicate because of
>> specific system level requirements to function.
>>
>> WOW64
>> At startup, Wow64.dll loads the x86 version of Ntdll.dll and runs its
>> initialization code, which loads all necessary 32-bit DLLs. Nearly all
>> 32-bit DLLs are unmodified copies of 32-bit Windows XP binaries. However,
>> some of these DLLs have knowledge of WOW64, usually because they share
>> memory with 64-bit processes.
>>
>> Instead of using the x86 system-service call sequence; 32-bit binaries
>> making system calls are rebuilt to use a custom calling sequence. This
>> new
>> sequence is inexpensive for WOW64 to intercept because it remains
>> entirely
>> in user mode. When the new calling sequence is detected, the WOW64 CPU
>> transitions back to native 64-bit mode and calls into (Wow64.dll).
>> Thunking
>> is done in user mode to reduce the impact on the 64-bit kernel, and to
>> reduce the risk of a bug in the thunk causing a kernel-mode crash, data
>> corruption, or a security hole. The thunks extract arguments from the
>> 32-bit
>> stack, extend them to 64 bits, and then make the native system call.
>>
>> WOW64 enables 32-bit applications to take advantage of the 64-bit kernel.
>> Therefore, 32-bit applications can use a larger number of kernel handles
>> and
>> window handles. However, 32-bit applications cannot create as many
>> threads
>> under WOW64 as they can on x86, because there is less virtual address
>> space
>> available, and each thread contains a 64-bit stack (usually 512K).
>>
>> Now you should understand why 32 bit applications are able to run on 64
>> bit
>> Windows.
>> --
>> Andre
>> Extended64 | http://www.extended64.com
>> Blog | http://www.extended64.com/blogs/andre
>> http://spaces.msn.com/members/adacosta
>> FAQ for MS AntiSpy http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm
>>
>> "bob" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> >I am able to run 32-bit applications on my 64-bit operating system, so
>> > presumably there's a translator sitting inbetween the application and
>> > the
>> > OS
>> > that converts the bits to the appropriate length.
>> >
>> > Why can't this be done with the drivers? It doesn't need to negate the
>> > need
>> > for real 64-bit drivers, but something, anything, even with limited
>> > speed
>> > or
>> > functionality is better than nothing which is what I have now.
>> >
>> > <vent>
>> > Not counting my motherboard drivers, currently I only have only 1
>> > 64-bit
>> > driver (video card) available to me for all of my hardware and
>> > peripherals. I
>> > upgraded to x64 because I was told it take full advantage of my
>> > processor
>> > and
>> > be twice as fast, this has not been the case. I've not noticed any
>> > gains
>> > in
>> > using x64, only limitations.
>> >
>> > I've hung in for quite a while now hoping that drivers would be
>> > available,
>> > but I've now lost all hope. I can't think of a reason that anyone
>> > would
>> > use
>> > x64 other than to post here and keep Microsoft informed of what
>> > hardware
>> > they
>> > have that doesn't work.
>> >
>> > So please, Microsoft, give us something that will make our 32-bit
>> > drivers
>> > work or tell Intel and AMD to stop making 64-bit processors because
>> > there's
>> > not a functioning operating system available that supports them.
>> > </vent>

>>
>>
>>



 
Reply With Quote
 
Rick
Guest
Posts: n/a
 
      07-02-2005
If you're a stupid as you profess to be in your post, then how the hell
did you ever figure out how to install x64?

If you think you are smarter than Microsoft, then write the necessary
software yourself to do what you want it to do!

bob wrote:
> I am able to run 32-bit applications on my 64-bit operating system, so
> presumably there's a translator sitting inbetween the application and the OS
> that converts the bits to the appropriate length.
>
> Why can't this be done with the drivers? It doesn't need to negate the need
> for real 64-bit drivers, but something, anything, even with limited speed or
> functionality is better than nothing which is what I have now.
>
> <vent>
> Not counting my motherboard drivers, currently I only have only 1 64-bit
> driver (video card) available to me for all of my hardware and peripherals. I
> upgraded to x64 because I was told it take full advantage of my processor and
> be twice as fast, this has not been the case. I've not noticed any gains in
> using x64, only limitations.
>
> I've hung in for quite a while now hoping that drivers would be available,
> but I've now lost all hope. I can't think of a reason that anyone would use
> x64 other than to post here and keep Microsoft informed of what hardware they
> have that doesn't work.
>
> So please, Microsoft, give us something that will make our 32-bit drivers
> work or tell Intel and AMD to stop making 64-bit processors because there's
> not a functioning operating system available that supports them.
> </vent>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is there any way to tell the difference between native Microsoft OS drivers from third-party? Spin Computer Support 3 11-05-2008 06:36 PM
Difference between Python CGI applications and Php applications praba kar Python 2 05-04-2005 06:49 PM
Difference between bin and obj directories and difference between project references and dll references jakk ASP .Net 4 03-22-2005 09:23 PM
difference between web applications and applicaitons Timothy V ASP .Net 1 02-07-2004 05:12 PM
Exact difference between 'const char *' and 'char *', also diff between 'const' and 'static' Santa C Programming 1 07-17-2003 02:10 PM



Advertisments