«

Drivers will take time, the product was released only 2 months ago, so
things will smooth out over time, I won't be surprised if we see a plethora
of drivers and software applications supporting x64 by fall or winter.
--
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:154CBB11-C76A-4AA8-8931-...
> 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:C573BBD0-D240-44D4-8E8C-...
>> > 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>
>>
>>
>>

The BJC-8000 driver seems to be working for most Canon printers. Install
that one and you can read my instructions in another post on how to port it
to your printer if it does not automatically select your printer.


"bob" <> wrote in message
news:2B2F8F88-3712-4EC2-B11F-...
> 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-----
>>

Charlie, would you call WOW64, Microsofts version of Rosetta?
--
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

"Charlie Russel - MVP" <> wrote in message
news:...
> 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:C573BBD0-D240-44D4-8E8C-...
>>>> 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>
>
>

I am running the 64 bit beta version and my Canon i560 wont work.
Canon has informed me that they currently have no drivers for 64 bit systems
andI don't want to buy a new printer so it's back to 32 bit XP unless
lsomeone knows of a generic driver that will work?????
"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>

I am sure the BJC-8000 driver will work with that machine. See my
instructions elsewhere on porting it to the proper USB port if it doesn't
set up when you install that 'printer'


"neil1255" <> wrote in message
news:8090E148-F654-4DC2-A2F8-...
>I am running the 64 bit beta version and my Canon i560 wont work.
> Canon has informed me that they currently have no drivers for 64 bit
> systems
> andI don't want to buy a new printer so it's back to 32 bit XP unless
> lsomeone knows of a generic driver that will work?????
> "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>

Actually 128-bit.
--
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:%...
> 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:3B5ABEF3-13C0-4907-B170-...
>>>> 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:C573BBD0-D240-44D4-8E8C-...
>>>>> >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>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>
>

"bob" <> wrote in message
news:C573BBD0-D240-44D4-8E8C-...
> 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.

AMD64 (aka EM64T) provides direct hardware support for 16/32-bit user
mode under a 64-bit OS, but it has a hard requirement for the OS to be
fully 64-bit. Since drivers are part of the OS, they must be 64-bit as
well.

Now, I suppose someone truly perverse could find a way to translate
32-bit drivers into 64-bit ones, or provide some sort of emulation, but
drivers are by their very nature extremely unportable and expect to have
access to all sorts of things that emulation or translation can't
feasibly take into account. In short, it's a _lot_ simpler for the HW
vendors to port their drivers (even when multiplied by the thousands of
drivers out there) than it is for MS to support 32-bit drivers on an x64
system.

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

Linux works just fine As does XP32.

Seriously though, the only XP64 driver problem I've run into so far is
Acrobat. You may say I lucked out because all my hardware is from
vendors who provide 64-bit drivers, but I've been watching very
carefully over the last year or so when I've done upgrades to make sure
that'd be the case.

Shame on all the vendors who can't f'ing recompile their drivers once or
twice in the last couple years -- this isn't rocket science. Make a
note of what doesn't work and replace it with something from a vendor
who adequately supports their products.

I bet all of this driver debate is why MS decided not to release XP64 as
a retail product -- there's just too many missing drivers right now to
let the clueless masses buy it off the shelf. Maybe in another year or
two...

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

You need to get educated! AMD64 is NOT aka EM64T!!!!!!!!!!!

EM64T was Intel's pathetic effort to imitate AMD64 without publicly
admitting AMD64 has the brains and the balls to do something Intel was
too chicken and too stupid to even think of on their own!!!!


Stephen Sprunk wrote:
> AMD64 (aka EM64T) provides direct hardware support for 16/32-bit user
> mode under a 64-bit OS, but it has a hard requirement for the OS to be
> fully 64-bit. Since drivers are part of the OS, they must be 64-bit as
> well.
>
> Now, I suppose someone truly perverse could find a way to translate
> 32-bit drivers into 64-bit ones, or provide some sort of emulation, but
> drivers are by their very nature extremely unportable and expect to have
> access to all sorts of things that emulation or translation can't
> feasibly take into account. In short, it's a _lot_ simpler for the HW
> vendors to port their drivers (even when multiplied by the thousands of
> drivers out there) than it is for MS to support 32-bit drivers on an x64
> system.
>
>
>><vent>
>>...
>>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>
>
>
> Linux works just fine As does XP32.
>
> Seriously though, the only XP64 driver problem I've run into so far is
> Acrobat. You may say I lucked out because all my hardware is from
> vendors who provide 64-bit drivers, but I've been watching very
> carefully over the last year or so when I've done upgrades to make sure
> that'd be the case.
>
> Shame on all the vendors who can't f'ing recompile their drivers once or
> twice in the last couple years -- this isn't rocket science. Make a
> note of what doesn't work and replace it with something from a vendor
> who adequately supports their products.
>
> I bet all of this driver debate is why MS decided not to release XP64 as
> a retail product -- there's just too many missing drivers right now to
> let the clueless masses buy it off the shelf. Maybe in another year or
> two...
>
> S
>

Normally, I wouldn't bother with a reply to such a dim-witted post but this
isn't the first time you made such uninformed statements. Very interesting
that you feel the "EM64T was Intel's pathetic effort to imitate AMD64"
especially since Intel released a 64 bit microprocessor (Feb 27, 1989) two
years before AMD manufactured their first processor, the Am386, in 1991
(nearly three years after the Intel 386SX). I'll post references for these
dates if you like. AMD is an excellent company to be sure and I respect
their decision years ago to optimize their processors to the old x86
instruction set rather than concentrate on new op codes as Intel did. It was
a strategy that allows those of you with AMD processors to enjoy a general
benefit in terms of speed today.

Jumping off the deep end with unfounded inflammatory statements after
suggesting that someone else "get educated!" is not a very good method of
garnering credibility.



"Rick" <> wrote in message
news:%...
> You need to get educated! AMD64 is NOT aka EM64T!!!!!!!!!!!
>
> EM64T was Intel's pathetic effort to imitate AMD64 without publicly
> admitting AMD64 has the brains and the balls to do something Intel was too
> chicken and too stupid to even think of on their own!!!!
>
>
> Stephen Sprunk wrote:
>> AMD64 (aka EM64T) provides direct hardware support for 16/32-bit user
>> mode under a 64-bit OS, but it has a hard requirement for the OS to be
>> fully 64-bit. Since drivers are part of the OS, they must be 64-bit as
>> well.
>>
>> Now, I suppose someone truly perverse could find a way to translate
>> 32-bit drivers into 64-bit ones, or provide some sort of emulation, but
>> drivers are by their very nature extremely unportable and expect to have
>> access to all sorts of things that emulation or translation can't
>> feasibly take into account. In short, it's a _lot_ simpler for the HW
>> vendors to port their drivers (even when multiplied by the thousands of
>> drivers out there) than it is for MS to support 32-bit drivers on an x64
>> system.

I stand corrected, AMD developed a "reverse-engineered version of the 8080A
standard processor" (for real, I copied that straight from AMDs website) in
1975.

"Intel_Fan" <> wrote in message
news:uLaZ%...
> Normally, I wouldn't bother with a reply to such a dim-witted post but
> this isn't the first time you made such uninformed statements. Very
> interesting that you feel the "EM64T was Intel's pathetic effort to
> imitate AMD64" especially since Intel released a 64 bit microprocessor
> (Feb 27, 1989) two years before AMD manufactured their first processor,
> the Am386, in 1991 (nearly three years after the Intel 386SX). I'll post
> references for these dates if you like. AMD is an excellent company to be
> sure and I respect their decision years ago to optimize their processors
> to the old x86 instruction set rather than concentrate on new op codes as
> Intel did. It was a strategy that allows those of you with AMD processors
> to enjoy a general benefit in terms of speed today.
>
> Jumping off the deep end with unfounded inflammatory statements after
> suggesting that someone else "get educated!" is not a very good method of
> garnering credibility.
>
>
>
> "Rick" <> wrote in message
> news:%...
>> You need to get educated! AMD64 is NOT aka EM64T!!!!!!!!!!!
>>
>> EM64T was Intel's pathetic effort to imitate AMD64 without publicly
>> admitting AMD64 has the brains and the balls to do something Intel was
>> too chicken and too stupid to even think of on their own!!!!
>>
>>
>> Stephen Sprunk wrote:
>>> AMD64 (aka EM64T) provides direct hardware support for 16/32-bit user
>>> mode under a 64-bit OS, but it has a hard requirement for the OS to be
>>> fully 64-bit. Since drivers are part of the OS, they must be 64-bit as
>>> well.
>>>
>>> Now, I suppose someone truly perverse could find a way to translate
>>> 32-bit drivers into 64-bit ones, or provide some sort of emulation, but
>>> drivers are by their very nature extremely unportable and expect to have
>>> access to all sorts of things that emulation or translation can't
>>> feasibly take into account. In short, it's a _lot_ simpler for the HW
>>> vendors to port their drivers (even when multiplied by the thousands of
>>> drivers out there) than it is for MS to support 32-bit drivers on an x64
>>> system.
>
>