What's the difference between drivers and applications

Discussion in 'Windows 64bit' started by =?Utf-8?B?Ym9i?=, Jul 2, 2005.

  1. 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>
     
    =?Utf-8?B?Ym9i?=, Jul 2, 2005
    #1
    1. Advertising

  2. =?Utf-8?B?Ym9i?=

    Jerry Guest

    You are venting in the wrong place. Drivers are the responsibility of the
    hardware manufacturers, not Microsoft or Intel.

    "bob" <> wrote in message
    news:...
    >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>
     
    Jerry, Jul 2, 2005
    #2
    1. Advertising

  3. 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" <> wrote in message
    news:...
    >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>
     
    Andre Da Costa [Extended64], Jul 2, 2005
    #3
  4. 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" <> wrote in message
    > news:...
    > >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>

    >
    >
    >
     
    =?Utf-8?B?Ym9i?=, Jul 2, 2005
    #4
  5. 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" <> wrote in message
    news:...
    > 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" <> wrote in message
    >> news:...
    >> >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>

    >>
    >>
    >>
     
    Andre Da Costa [Extended64], Jul 2, 2005
    #5
  6. 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" <> wrote in message
    news:...
    > 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" <> wrote in message
    >> news:...
    >> >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>

    >>
    >>
    >>
     
    Andre Da Costa [Extended64], Jul 2, 2005
    #6
  7. =?Utf-8?B?Ym9i?=

    WM Guest

    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" <> wrote in message
    news:...
    > 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" <> wrote in message
    >> news:...
    >> >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>

    >>
    >>
    >>
     
    WM, Jul 2, 2005
    #7
  8. 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" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    >> 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" <> wrote in message
    >>> news:...
    >>> >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>
    >>>
    >>>
    >>>

    >
    >
     
    Andre Da Costa [Extended64], Jul 2, 2005
    #8
  9. 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" <> wrote in message
    news:...
    > 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" <> wrote in message
    >> news:...
    >> >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>

    >>
    >>
    >>
     
    Colin Barnhorst, Jul 2, 2005
    #9
  10. =?Utf-8?B?Ym9i?=

    Rick Guest

    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>
     
    Rick, Jul 2, 2005
    #10
  11. Let's not turn this into the Flame Wars: Episode 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

    "Rick" <> wrote in message
    news:e05h%...
    > 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>
     
    Andre Da Costa [Extended64], Jul 3, 2005
    #11
  12. =?Utf-8?B?Ym9i?=

    WM Guest

    True enough - would those be 48-bit drivers or 96-bit drivers? ;-)


    "Andre Da Costa [Extended64]" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    >> 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" <> wrote in message
    >> news:...
    >>> 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" <> wrote in message
    >>>> news:...
    >>>> >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>
    >>>>
    >>>>
    >>>>

    >>
    >>

    >
    >
     
    WM, Jul 3, 2005
    #12
  13. The issue is the difference between kernel mode and user mode. The operating
    system, and its drivers, run in kernel mode. That all needs to be 64-bit.
    Applications run in User mode. There is a translation layer that handles the
    32-bit to 64-bit called WOW64 (Windows on Windows 64-bit). To do a
    translation layer that translated in kernel mode would probably be
    technically possible, but would have a seriously deleterious effect on the
    speed and stability of the entire operating system.

    64-bit computing is NOT for everyone yet. It _is_ a faster, and more powerful
    operating system that can make a stunning difference in some applications.
    But for most existing 32-bit applications the speed is essentially the same
    and there's no real gain. That will change over time as more 64-bit versions
    of applications become available. But in the meantime, x64 Edition is for
    those who understand the price of being an "early adopter" and don't mind
    that price. It is not for everyone, and it does require some careful buying
    decisions to ensure full compatibility.


    --
    Charlie.
    http://www.msmvps.com/xperts64/


    bob wrote:
    > 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" <> wrote in message
    >> news:...
    >>> 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>
     
    Charlie Russel - MVP, Jul 3, 2005
    #13
  14. =?Utf-8?B?Ym9i?=

    Randy Guest

    Sounds like you bit before doing enough research, Bob... it's much like
    buying a new car in that you can't base your pruchase decision merely on the
    surface hype or heresay you get on the product.

    On the other hand, you should feel confident that in time (likely within a
    year of its first release to manufacturers), your purchase *will* come to
    fruition and work not only as promised, but likely to much higher levels of
    your satisfaction than originally held. Technology advances take time, but
    overall, you were right to make the purchase. You just got into the game
    before it was ready for you.

    So now you have to decide if you want to take the time, energy, and
    frustration required to make things work for you as needed with what you
    currently have, or if you'd rather put x64 on the back burner for a while
    and simply run your existing apps on a 32-bit OS. That's what a lot of us
    are doing... at least keeping a dual-boot setup in order to get familiarized
    with x64 while still maintaining a functional x32 system on which to
    continue our day-to-day work with something we know works.


    "bob" <> wrote in message
    news:...
    > 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>
     
    Randy, Jul 3, 2005
    #14
  15. bob wrote:

    > 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?


    As in the WoW64 layer, this transaction is always an imprecise business.
    The application interface (API) is well defined, so the chance of
    making it work in most cases are pretty high, which is why WoW64 works.

    The driver interface to the kernel on the other hand is a lot more
    complex, and translating it is less likely to lead to the desired
    results. That said, it has been done a few times, but not for general
    purposes, but only for a certain class of drivers. Windows network
    drivers can be used under Linux, and some Linux drivers can be loaded on
    BSD.

    Microsoft could do the same for 32bit drivers on x64, but it would only
    work for the targeted class on drivers, and there would always be some
    of drivers that do not work.

    > For example, if I ran vmware's pc emulator on x64, would I finally be able
    > to print with my 32-bit drivers?For the application interface (API),


    That depends again. VMware does the translation at a different point: it
    creates "virtual devices" for the virtual machine. So if you printer has
    a USB interface, it should work, because USB has a well defined
    interface abstraction. A parallel printer may or may not work, depending
    on how it uses the parallel interface. GDI printers do not works (AFAIK).

    But with printers you have an additional problem: you need printer
    drivers both on the server and on the client. It should be possible to
    work around this problem by using a device independent print format,
    such as postscript, but that is difficult to set up.

    So it seems you are out of luck. Ask your printer manufacturer to update
    the drivers.

    >>>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.


    Yes, I came to the same conclusion after the customer preview. There
    were lot of difficulties, and the potential for many more problems. On
    the other hand, I have not seen any interesting 64bit application yet.

    Thomas
     
    Thomas Steffen, Jul 3, 2005
    #15
  16. Cheers, Randy.

    I'm sorry for my vent yesterday and I agree the smart thing would have been
    to set up a dual boot system, but I didn't realize exactly how beta x64 was
    going to be until I waited and waited and no drivers appeared. I had to print
    out some directions yesterday and instead of taking the time to manually
    transcribe the pages by hand, I went off on a holy grailish quest to find my
    drivers once and for all; And before appearing in here to vent I spent the
    whole morning going round in circles.

    I haven't got a cheap printer. I paid around $500 for it last year. It's
    frustrating to see the thing going down in price and being made obsolete
    before I get my usage out of it.

    I'll try and set up a dual boot when I have time.


    "Randy" wrote:

    > Sounds like you bit before doing enough research, Bob... it's much like
    > buying a new car in that you can't base your pruchase decision merely on the
    > surface hype or heresay you get on the product.
    >
    > On the other hand, you should feel confident that in time (likely within a
    > year of its first release to manufacturers), your purchase *will* come to
    > fruition and work not only as promised, but likely to much higher levels of
    > your satisfaction than originally held. Technology advances take time, but
    > overall, you were right to make the purchase. You just got into the game
    > before it was ready for you.
    >
    > So now you have to decide if you want to take the time, energy, and
    > frustration required to make things work for you as needed with what you
    > currently have, or if you'd rather put x64 on the back burner for a while
    > and simply run your existing apps on a 32-bit OS. That's what a lot of us
    > are doing... at least keeping a dual-boot setup in order to get familiarized
    > with x64 while still maintaining a functional x32 system on which to
    > continue our day-to-day work with something we know works.
    >
    >
    > "bob" <> wrote in message
    > news:...
    > > 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>

    >
    >
    >
     
    =?Utf-8?B?Ym9i?=, Jul 3, 2005
    #16
  17. You are perfectly correct.

    I was stupid enough to install x64.


    "Rick" wrote:

    > 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>

    >
     
    =?Utf-8?B?Ym9i?=, Jul 3, 2005
    #17
  18. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    bob wrote:
    > Cheers, Randy.
    >
    > I'm sorry for my vent yesterday and I agree the smart thing would have been
    > to set up a dual boot system, but I didn't realize exactly how beta x64 was
    > going to be until I waited and waited and no drivers appeared. I had to print
    > out some directions yesterday and instead of taking the time to manually
    > transcribe the pages by hand, I went off on a holy grailish quest to find my
    > drivers once and for all; And before appearing in here to vent I spent the
    > whole morning going round in circles.
    >
    > I haven't got a cheap printer. I paid around $500 for it last year. It's
    > frustrating to see the thing going down in price and being made obsolete
    > before I get my usage out of it.
    >
    > I'll try and set up a dual boot when I have time.
    >


    Hello Bob,

    What printer do you have?


    - --
    Steve Thompson
    Key ID: 0x495F423B http://pgpkeys.telering.at
    CBEC CFA9 94DB B835 5B86 4F7B 5EFF 6369 495F 423B

    Pre-Installation Guide to Windows XP Professional x64 Edition
    http://home.comcast.net/~stthomp/
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (MingW32)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFCyAJIXv9jaUlfQjsRAic1AJ9gVDAT3D7JMHzsT/J57sJbT39Q0ACeKIJw
    bNqXGxHTNmvSrRbqItG0wzM=
    =FQ2E
    -----END PGP SIGNATURE-----
     
    Steve Thompson, Jul 3, 2005
    #18
  19. Hi, Steve.

    It's a Canon IP8500.


    "Steve Thompson" wrote:

    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > bob wrote:
    > > Cheers, Randy.
    > >
    > > I'm sorry for my vent yesterday and I agree the smart thing would have been
    > > to set up a dual boot system, but I didn't realize exactly how beta x64 was
    > > going to be until I waited and waited and no drivers appeared. I had to print
    > > out some directions yesterday and instead of taking the time to manually
    > > transcribe the pages by hand, I went off on a holy grailish quest to find my
    > > drivers once and for all; And before appearing in here to vent I spent the
    > > whole morning going round in circles.
    > >
    > > I haven't got a cheap printer. I paid around $500 for it last year. It's
    > > frustrating to see the thing going down in price and being made obsolete
    > > before I get my usage out of it.
    > >
    > > I'll try and set up a dual boot when I have time.
    > >

    >
    > Hello Bob,
    >
    > What printer do you have?
    >
    >
    > - --
    > Steve Thompson
    > Key ID: 0x495F423B http://pgpkeys.telering.at
    > CBEC CFA9 94DB B835 5B86 4F7B 5EFF 6369 495F 423B
    >
    > Pre-Installation Guide to Windows XP Professional x64 Edition
    > http://home.comcast.net/~stthomp/
    > -----BEGIN PGP SIGNATURE-----
    > Version: GnuPG v1.4.1 (MingW32)
    > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
    >
    > iD8DBQFCyAJIXv9jaUlfQjsRAic1AJ9gVDAT3D7JMHzsT/J57sJbT39Q0ACeKIJw
    > bNqXGxHTNmvSrRbqItG0wzM=
    > =FQ2E
    > -----END PGP SIGNATURE-----
    >
     
    =?Utf-8?B?Ym9i?=, Jul 3, 2005
    #19
  20. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    bob wrote:
    > Hi, Steve.
    >
    > It's a Canon IP8500.
    >


    Hello again Bob,

    I've done quite a bit of searching around with all of the resources that
    are available to me and it doesn't look like Canon will be supporting
    this particular printer any time soon. But I wouldn't give up hope.

    I downloaded the driver package for Windows XP 32 bit for your printer
    and compared the .INF file to the Windows XP x64 Edition printer driver
    for the i990 wich can be found here
    http://alpha03.c-wss.com/inc/ApplServlet?SV=WWUCA900 . I don't know if
    it's possible to decorate the i990's .INF for the IP8500 or not but it's
    definitely worth a shot.

    Other than using that approach, if you have another computer with
    Windows XP on it you could network the two together and print through
    the XP 32 bit machine. The other option, as others have suggested, is to
    dual boot.

    I would certainly look into decorating the i990's driver to compliment
    the IP8500 and see how far you get. The worst that could happen is that
    it won't work. It doesn't work as is so you have nothing to lose.

    Also, this is a photo printer so basically it's just an ink jet printer
    with more cartridges. For basic printing needs, Windows x64 does have a
    few Canon drivers built in that may get you by if it can be recognized.
    Which brings me to one more question. Do you connect this printer via
    USB or parallel?

    >
    > "Steve Thompson" wrote:
    >
    >
    > bob wrote:
    >
    >>Cheers, Randy.

    >
    >>I'm sorry for my vent yesterday and I agree the smart thing would have been
    >>to set up a dual boot system, but I didn't realize exactly how beta x64 was
    >>going to be until I waited and waited and no drivers appeared. I had to print
    >>out some directions yesterday and instead of taking the time to manually
    >>transcribe the pages by hand, I went off on a holy grailish quest to find my
    >>drivers once and for all; And before appearing in here to vent I spent the
    >>whole morning going round in circles.

    >
    >>I haven't got a cheap printer. I paid around $500 for it last year. It's
    >>frustrating to see the thing going down in price and being made obsolete
    >>before I get my usage out of it.

    >
    >>I'll try and set up a dual boot when I have time.

    >
    >
    > Hello Bob,
    >
    > What printer do you have?
    >
    >
    > --
    > Steve Thompson
    > Key ID: 0x495F423B http://pgpkeys.telering.at
    > CBEC CFA9 94DB B835 5B86 4F7B 5EFF 6369 495F 423B
    >
    > Pre-Installation Guide to Windows XP Professional x64 Edition
    > http://home.comcast.net/~stthomp/


    - --
    Steve Thompson
    Key ID: 0x495F423B http://pgpkeys.telering.at
    CBEC CFA9 94DB B835 5B86 4F7B 5EFF 6369 495F 423B

    Pre-Installation Guide to Windows XP Professional x64 Edition
    http://home.comcast.net/~stthomp/
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (MingW32)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFCyB68Xv9jaUlfQjsRAsQ+AJsEOGB0GDh8czwRyd711ptJg56NPwCdFaB5
    R0g6/JfFr4lDbmhm/2tpfWE=
    =FQaG
    -----END PGP SIGNATURE-----
     
    Steve Thompson, Jul 3, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tony Warburton

    difference between 802.3b and 802.11b

    Tony Warburton, Nov 25, 2004, in forum: Wireless Networking
    Replies:
    2
    Views:
    3,608
    =?Utf-8?B?UGF2ZWwgQS4=?=
    Nov 25, 2004
  2. fkissam

    Palm OS software to link between Applications

    fkissam, Feb 20, 2004, in forum: Computer Support
    Replies:
    0
    Views:
    458
    fkissam
    Feb 20, 2004
  3. Galpersonal
    Replies:
    8
    Views:
    1,063
    universal4
    Aug 13, 2006
  4. Replies:
    0
    Views:
    829
  5. Spin
    Replies:
    3
    Views:
    565
    Kelly
    Nov 5, 2008
Loading...

Share This Page