Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

A long overdue demise

Don_Burn_1Don_Burn_1 Member Posts: 4,311
For those who have not seen it, the Windows Server Division said Windows
Server 2008 R2 and Visual Studio 2010 are the last to support Itanium.
See
http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server
-2008-r2-to-phase-out-itanium.aspx Finally the Itanic is sinking under
the waves.


Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

Comments

  • Prokash_Sinha-1Prokash_Sinha-1 Member - All Emails Posts: 1,214
    I heard about it, and wonder what and why Intel is moving in that directions. Is it becoming purely Unix ( and its derivatives )?. Now they have IA-32 code level compatibility mode!

    Huh, my adb produces itanium code. Hope not in the wrong end of the rope!

    -pro

    On Apr 5, 2010, at 10:06 AM, Don Burn wrote:

    > For those who have not seen it, the Windows Server Division said Windows
    > Server 2008 R2 and Visual Studio 2010 are the last to support Itanium.
    > See
    > http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server
    > -2008-r2-to-phase-out-itanium.aspx Finally the Itanic is sinking under
    > the waves.
    >
    >
    > Don Burn (MVP, Windows DKD)
    > Windows Filesystem and Driver Consulting
    > Website: http://www.windrvr.com
    > Blog: http://msmvps.com/blogs/WinDrvr
    >
    >
    >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,262
    <QUOTE>
    Is it becoming purely Unix ( and its derivatives )
    </QUOTE>

    I know it's been announced that RHEL is dropping support for the Itanic as well (in RHEL 6, IIRC).

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • anton_bassovanton_bassov Member Posts: 5,008
    > Is it becoming purely Unix ( and its derivatives )?.

    AFAIK, RedHat had announced the same strategy concerning IA64 back in January . It is understandable that kernel.org will provide IA64 support for quite a while - the only question is who is actually going to take advantage of it in the Linux world. Therefore, I think that out of all UNICes HP is the main candidate - AFAIK, they made quite significant investment in this arch, so that I don't think they will abandon it that quickly....


    Anton Bassov
  • Prokash_Sinha-1Prokash_Sinha-1 Member - All Emails Posts: 1,214
    Yep, you are right. RedHat has been ported to IA64. Also SPARC is under-nurished these days. AIX also supports some IA64, and kernel.org has a port for it too. I don't know but I think novel's suse also have a port.

    -pro




    On Apr 5, 2010, at 7:44 PM, xxxxx@hotmail.com wrote:

    >> Is it becoming purely Unix ( and its derivatives )?.
    >
    > AFAIK, RedHat had announced the same strategy concerning IA64 back in January . It is understandable that kernel.org will provide IA64 support for quite a while - the only question is who is actually going to take advantage of it in the Linux world. Therefore, I think that out of all UNICes HP is the main candidate - AFAIK, they made quite significant investment in this arch, so that I don't think they will abandon it that quickly....
    >
    >
    > Anton Bassov
    >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I believe that they were the original architects/developers; Intel joined them shortly after they started.

    Or something like that.


    mm
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    On Tue, Apr 6, 2010 at 5:32 AM, <xxxxx@osr.com> wrote:
    > <QUOTE>
    > Is it becoming purely Unix ( and its derivatives )
    > </QUOTE>
    >
    > I know it's been announced that RHEL is dropping support for the Itanic as well (in RHEL 6, IIRC).
    >

    I know of no one that has Itanium hardware and runs anything else but
    OpenVMS or HP-UX on it. Microsoft's decision and Red Hat's decision
    are understandable from a business point of view.

    --
    Aram Hăvărneanu
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    On Tue, Apr 6, 2010 at 5:11 AM, Prokash Sinha <xxxxx@garlic.com> wrote:
    > I heard about it, and wonder what and why Intel is moving in that directions. Is it becoming purely Unix ( and its derivatives )?. Now they have IA-32 code level compatibility mode!
    >

    I think it's the other way around. Early IA-64 had IA-32 compatibility
    mode, but the performance sucked so they dropped it. Now the IA-32
    compatibility is handled in software and works much better.

    I've always found somewhat funny and sad at the same time that if I
    want to compile IA-64 binaries ON Itanium, I'd have to run IA-32 cross
    compiler in emulation mode...
    --
    Aram Hăvărneanu
  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    On Tue, Apr 6, 2010 at 5:59 AM, Prokash Sinha <xxxxx@garlic.com> wrote:
    > Yep, you are right. RedHat has been ported to IA64. Also SPARC is under-nurished these days. AIX also supports some IA64, and kernel.org has a port for it too. I don't know but I think novel's suse also have a port.
    >

    AIX doesn't support anything but IBM POWER. There was an early porting
    effort to IA-64 circa 2000-2001, but was abandoned early. Just as
    there was a SPARC porting effort for Windows that was abandoned in NT
    4 days.

    The only *mainstream* operating systems running on IA-64 this days are
    HP-UX, OpenVMS, Linux and various BSDs. From this list, only HP-UX and
    OpenVMS matter because you can't run current versions on something
    else.

    IA-32 has become too expensive to replace. All the other platforms are
    for some specific niche. I think this is caused partially by
    Microsoft. UNIX/Linux vendors *AND* ISVs have adapted extremely fast
    to architecture changes. It has never taken more then an year for any
    historic transition to occur (including x86 -> x64) in UNIX/Linux
    world.

    In Windows, even a simple transition like x86 -> x64 takes forever,
    Microsoft provides x64 software only for Windows and SQL-SERVER. What
    about Office and Visual Studio? (I hear Office 2010 will run on x64).
    Why does Visual Studio, when running on 64 bit windows and targets 64
    bit binaries, use 32 bit cross compilers?

    I also blame Intel for the slow 64 bit transition. When 64 bit SPARC
    appeared, compiler could produce binaries that used new 64 bit
    instructions and 32 bit pointers. This is important because a lot of
    software doesn't need 64 bit pointers (decreasing address bus pressure
    and increasing memory throughput) and because new 64 bit plugins could
    work with old 32 bit software!

    /end rant.

    --
    Aram Hăvărneanu
  • James_HarperJames_Harper Member Posts: 1,615
    >
    > On Tue, Apr 6, 2010 at 5:59 AM, Prokash Sinha <xxxxx@garlic.com>
    wrote:
    > > Yep, you are right. RedHat has been ported to IA64. Also SPARC is
    under-
    > nurished these days. AIX also supports some IA64, and kernel.org has a
    port
    > for it too. I don't know but I think novel's suse also have a port.
    > >
    >
    > AIX doesn't support anything but IBM POWER. There was an early porting
    > effort to IA-64 circa 2000-2001, but was abandoned early. Just as
    > there was a SPARC porting effort for Windows that was abandoned in NT
    > 4 days.
    >
    > The only *mainstream* operating systems running on IA-64 this days are
    > HP-UX, OpenVMS, Linux and various BSDs. From this list, only HP-UX and
    > OpenVMS matter because you can't run current versions on something
    > else.

    FWIW (not much :), Xen also runs/ran on IA64. Someone asked if I could
    look at porting my PV drivers to IA64. I looked, but it was a fairly big
    change so it didn't happen. I don't feel so bad about it now :)

    > In Windows, even a simple transition like x86 -> x64 takes forever,
    > Microsoft provides x64 software only for Windows and SQL-SERVER.

    And Exchange (AMD64, not sure about IA64)

    James
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,262
    <QUOTE>
    IA-32 has become too expensive to replace. All the other platforms are
    for some specific niche. I think this is caused partially by
    Microsoft. UNIX/Linux vendors *AND* ISVs have adapted extremely fast
    to architecture changes. It has never taken more then an year for any
    historic transition to occur (including x86 -> x64) in UNIX/Linux
    world.

    In Windows, even a simple transition like x86 -> x64 takes forever,
    Microsoft provides x64 software only for Windows and SQL-SERVER. What
    about Office and Visual Studio? (I hear Office 2010 will run on x64).
    Why does Visual Studio, when running on 64 bit windows and targets 64
    bit binaries, use 32 bit cross compilers?
    </QUOTE>

    There's so much nonsense in this I barely know where to start. I just HATE it when a post like this puts me in the position of having to defend and explain Microsoft to people who are so very obviously clueless.

    FIRST of all, without Microsoft there probably would BE no x64 as we know it today. Seriously. If you're not aware of this, you don't know the history of the chip or how the chip was developed.

    SECOND, *very* shortly after the AMD64's (Hammer) release, Windows was RTM'ed with x64 support. I don't call that "taking forever." Further, you'll note that when Windows-64 shipped with x64 support, it shipped with VERY good (not perfect, but VERY good) compatibility. Tons of down-level apps ran just fine as 32-bit apps. And those apps typically ran (and today do run) FASTER than they do on x86.

    And, by the way, "even a simple transition like x86 -> x64"? Simple? Really? From an OS point of view, that's SIMPLE? I don't think so.

    THIRD, *the* limiting problem for x64 has always been driver support. Linux systems don't support one TENTH of the devices supported by Windows. MSFT had the OS support, the core driver stack support. It took the ISV's *ages* to get their drivers 64-bit compliant. The only thing that caused 64-bit drivers to eventually be released was Microsoft's (heavy handed, for my tastes, but unfortunately required) policy of REQUIRING x64 drivers to be provided when x86 drivers were logo'ed by WHQL. If it was up to ISVs and OEMs, there STILL wouldn't be any 64-bit drivers.

    FINALLY, you entirely miss the point about x64 on Windows when you ask "What about Office and Visual Studio?" -- What ABOUT office and VS?? While I have no doubt that everything will eventually be native 64-bit (because 32-bit Windows will in time be deprecated)... in the mean time who gives a rat's ass if Office runs in 32-bit mode or 64-bit mode? Again, let me repeat, the 32-bit version runs faster on 64-bit Windows than on 32-bit Windows. We tend not to port things to different architectures here in the Windows world just for the sake of doing it, like they do on Linux.

    Now, I return you to the discussion of the IA64... Is that "Nearer My God To Thee" I hear playing in the background?

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,306
    Intel and HP should have paid me $10,000,000 to explain to them why the
    Multiflow design failed and why they were going to fail too. They could have
    saved x billiions and I would have the FU money to stop doing this crap.


    Mark Roddy


    On Mon, Apr 5, 2010 at 1:06 PM, Don Burn wrote:

    > For those who have not seen it, the Windows Server Division said Windows
    > Server 2008 R2 and Visual Studio 2010 are the last to support Itanium.
    > See
    > http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server
    > -2008-r2-to-phase-out-itanium.aspx Finally the Itanic is sinking under
    > the waves.
    >
    >
    > Don Burn (MVP, Windows DKD)
    > Windows Filesystem and Driver Consulting
    > Website: http://www.windrvr.com
    > Blog: http://msmvps.com/blogs/WinDrvr
    >
    >
    >
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
  • Don_Burn_1Don_Burn_1 Member Posts: 4,311
    Ironically years ago I did a research paper for a major Intel partner
    that basically proved that the performance for anything other than
    specialized highly parallel applications was not there. I know the
    paper was forwarded to Intel. Years later I was interviewing at the
    same company and they were excited about the great benchmarks of IA64
    (though the chip was not release yet). I was having lunch with the head
    of advanced research and asked “Which benchmark towers of Hanoi or
    Stanford loops?” Ended up I sent them the paper again and their
    enthusiasm wained.

    Multiflow was truly a scam, they claimed great performance including
    having hardware (albeit running at slowed down clock speeds). When the
    company shutdown interestingly the hardware did not work, and no one
    could repo their performance numbers, of course all the major players
    moved on to positions at HP and Intel promising even better performance
    “on all applications” which of course never happened.


    Don Burn (MVP, Windows DKD)
    Windows Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr



    From: xxxxx@gmail.com [mailto:xxxxx@gmail.com] On Behalf
    Of Mark Roddy
    Posted At: Tuesday, April 06, 2010 10:19 AM
    Posted To: ntdev
    Conversation: A long overdue demise
    Subject: Re: A long overdue demise

     Intel and HP should have paid me $10,000,000 to explain to them why the
    Multiflow design failed and why they were going to fail too. They could
    have saved x billiions and I would have the FU money to stop doing this
    crap.
     
     
    Mark Roddy

    On Mon, Apr 5, 2010 at 1:06 PM, Don Burn <xxxxx@acm.org> wrote:
    For those who have not seen it, the Windows Server Division said Windows
    Server 2008 R2 and Visual Studio 2010 are the last to support Itanium.
    See
    http://blogs.technet.com/windowsserver/archive/2010/04/02/windows-server
    -2008-r2-to-phase-out-itanium.aspx  Finally the Itanic is sinking under
    the waves.


    Don Burn (MVP, Windows DKD)
    Windows Filesystem and Driver Consulting
    Website: http://www.windrvr.com
    Blog: http://msmvps.com/blogs/WinDrvr





    ---
    NTDEV is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer


    __________ Information from ESET Smart Security, version of virus
    signature database 5004 (20100406) __________

    The message was checked by ESET Smart Security.

    http://www.eset.com
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,262
    <QUOTE>
    Intel and HP should have paid me $10,000,000 to explain to them why the
    Multiflow design failed and why they were going to fail too. They could have
    saved x billiions and I would have the FU money to stop doing this crap.
    </QUOTE>

    I hereby nominate Mr. Roddy's post, above, for the highly sought-after Post Of The Week award (play trumpet sound here), with all the rights and privileges appurtenant thereto.

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Aram_Havarneanu-2Aram_Havarneanu-2 Member Posts: 161
    On Tue, Apr 6, 2010 at 5:14 PM, <xxxxx@osr.com> wrote:
    > FIRST of all, without Microsoft there probably would BE no x64 as we know it today.  Seriously. If you're not aware of this, you don't know the history of the chip or how the chip was developed.

    Oh, I am well aware of that fact. In fact, there's more to it! If it
    were not Microsoft, IA-32(e) as a whole not be as we know it today. I
    would be the same toy architecture it was 20 years ago when RISC ruled
    the market. But I think that if the mainstream arch people use today
    would be one of those kind of architectures, the world would be a
    better place.

    So yes, I thank Microsoft for making x64 as a better x86, but I don't
    like that the reason there was a need for x64 in the first place was
    the Microsoft ecosystem (not the company, but the whole ISV pool with
    their little apps).

    > SECOND, *very* shortly after the AMD64's (Hammer) release, Windows was RTM'ed with x64 support.

    So did NetBSD and Linux. In fact, the NetBSD port appeared *before*
    the silicon was out. It was developed on the Virtutech Simics
    Emulator. Just like Windows.

    > I don't call that "taking forever."

    But it does take forever. It is still not done. You think I was
    referring to Windows when in fact I am referring to the whole Windows
    ecosystem, with all ISVs doing their small apps and whatnot. When I
    did say "UNIX arch transitions happen quickly", I did not mean OS
    (kernel + support utilities) transition, as you might have assumed,
    but the transition of the whole ECOSYSTEM. Of COURSE every sane OS
    could be ported to whatever arch in about the same time, provided the
    complexity is about the same, but a couple of MONTHS after AMD64 got
    out, 99%, THOUSANDS of Linux application were running in 64 mode on
    it. Right now, my FreeBSD system reports over 17,000 64 bit ports of
    random UNIX applications. Compare that to Windows ecosystem, where
    only few vendors deliver 64 bit apps.

    > Further, you'll note that when Windows-64 shipped with x64 support, it shipped with VERY good (not perfect, but VERY good) compatibility.  Tons of down-level apps ran just fine as 32-bit apps.

    Depends on what you are comparing it with. Compared to Linux? Sure,
    but we all know Linux sucks, right (at least I do). Linux has no
    notion of backward/forward compatibility in the first place.

    Windows compatibility is pretty good, but behind Solaris
    compatibility. I don't know much about AIX and HP-UX, I only speak of
    what I know. At least Solaris doesn't have 32 bit binaries in SysWOW64
    and 64 bit binaries in System32...

    > And, by the way, "even a simple transition like x86 -> x64"?  Simple?  Really?  From an OS point of view, that's SIMPLE?  I don't think so.

    It is simple compared to a transition like PPC -> IA-32 or ALPHA ->
    Itanium or PA-RISC -> Intanium. Mac OS X switched from PPC to IA-32, a
    rather hard thing to do, and nobody noticed.

    > THIRD, *the* limiting problem for x64 has always been driver support.  Linux systems don't support one TENTH of the devices supported by Windows.  MSFT had the OS support, the core driver stack support.  It took the ISV's *ages* to get their drivers 64-bit compliant.  The only thing that caused 64-bit drivers to eventually be released was Microsoft's (heavy handed, for my tastes, but unfortunately required) policy of REQUIRING x64 drivers to be provided when x86 drivers were logo'ed by WHQL.  If it was up to ISVs and OEMs, there STILL wouldn't be any 64-bit drivers.

    But that is absolutely EXACTLY the same thing I am saying. The problem
    is because I typed "Microsoft" in my previous post, you ASSUME I was
    referring to the COMPANY, when in fact I was referring to the
    ECOSYSTEM. It may be my fault that I was not specific enough.

    And although I don't like Linux on any level (philosophy, code etc)
    and would not recommend it to any sane person, I must object to your
    statement regarding 10% of supported Windows devices. That is a gross
    overexageration, and in the server world I'd say (unfortunately!) that
    Linux supports pretty much the same hardware as Windows does.

    > FINALLY, you entirely miss the point about x64 on Windows when you ask "What about Office and Visual Studio?" -- What ABOUT office and VS??  While I have no doubt that everything will eventually be native 64-bit (because 32-bit Windows will in time be deprecated)... in the mean time who gives a rat's ass if Office runs in 32-bit mode or 64-bit mode?  Again, let me repeat, the 32-bit version runs faster on 64-bit Windows than on 32-bit Windows.  We tend not to port things to different architectures here in the Windows world just for the sake of doing it, like they do on Linux.

    Porting things to different architectures is always a very good thing
    to do. It means that the code quality will be higher and you'll catch
    more bugs.

    The thing goes like this. ISVs look at other ISVs and see that they
    are doing 32 bit only, therefore they decide that they shouldn't
    bother with 64 bit because others are not doing it. At least
    companies/people that I worked with think that way. And then nobody
    does 64 bit. And then Microsoft has to support 32 bit forever with all
    kind of ugly hacks like the SysWOW64 thing because ISVs can't be
    bothered to write correct code. IMHO, complete transition to 64 bit
    will happen only when Microsoft will FORCE people to do it.

    --
    Aram Hăvărneanu
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    I don't recall whether it was Ed Dekker or I who made this statement, but it
    was one of us, after we saw the announcement of the IA-64

    "Itanium is the 432 of the 90s"

    Does anyone remember the Intel 432 chip? Late1970s. A truly fascinating
    architecture, well ahead of its day, completely and utterly
    non-cost-effective, far too slow to be usable.

    The whole point of the IA-64 architecture was that you would not have to
    devote acres of silicon to producing the illusion of a synchronous CISC
    architecture on top of an asynchronous RISC architecture. I knew it was
    doomed the moment I read the statement that "the compiler will optimize the
    concurrency". I had a student, back when I was University faculty, who
    worked on optimizing horizontal microcode to maximize concurrency.
    Essentially, what you get is the NP-hard "bin packing problem". What saved
    him was that he was working with very small microstores (256 horizontal
    microinstructions, max) and had some heuristics that gave pretty good
    answers without wandering into NP-hard computations. So the idea that you
    could build a compiler which would solve an NP-hard problem, optimally, on
    every compilation, for large programs, seemed foolish (it sounded like some
    hardware geek figuring "we can do anything we want, and The Software Will
    Solve All Remaining Problems" Or, as I call it, the inevitable consequence
    of software illiteracy in hardware people, which I don't have to explain to
    THIS group!). Friends who are compiler experts have told me (I have not
    looked myself) that the code [for those who don't know: the IA64 can
    nominally pack three instructions into a 64-bit quadword, and control bits
    determine which instructions run concurrent with which other instructions
    within the quadword] that they see from IA-64 compilers producing output
    that "consists of one instruction and two NOPs per quadword" and a computer
    architecture expert once told me that "there is no way you can beat a
    pipelined superscalar architecture with an IA-64-style architecture" (he was
    the designer of several major RISC computer systems, which still sell to
    this day). Ultimately, everyone who ever saw the architecture predicted it
    was doomed, and it has merely taken a very long time to have Intel realize
    that. It took them years to see the 432 was doomed, also.

    joe
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,262
    Well, I'll allow myself the luxury of one additional reply and -- if there's any more to be said about this -- it needs to go to NTTalk.

    <QUOTE>
    I must object to your statement regarding 10% of supported Windows devices. That is a gross
    overexageration
    </QUOTE>

    Well, we disagree. I think I was being generous to Linux, frankly. OK, maybe you could convince me that Linux supports 20% of the devices that Windows support... but I think that's seriously pushing it. Now... I'm not talking about servers. I'm talking about devices supported AS A WHOLE. You're the one who mentioned Office and Visual Studio, neither of which typically run on servers.

    <QUOTE>
    Porting things to different architectures is always a very good thing
    to do. It means that the code quality will be higher and you'll catch
    more bugs.
    </QUOTE>

    Huh? Beyond the implicitly contained comment "a line by line code review is always a good thing to do, and will result in higher code quality and you'll catch bugs" I don't understand how this can be. Adding MORE CODE, or changing existing code so it works in a different environment but still works in the environment in which it was originally intended to run, results in FEWER bugs? Well, that's the first time anybody tried to tell me THAT. Sorry, I'm not buying it.

    <QUOTE>
    And then Microsoft has to support 32 bit forever with all
    kind of ugly hacks like the SysWOW64 thing because ISVs can't be
    bothered to write correct code
    </QUOTE>

    It's correct as 32-bit code. There's no NEED to update it.

    The x64 runs 32-bit code natively. There's no translation involved. The convergence layer in the OS is very thin, and comprises thunking from 32-bit to 64-bit, basically. 64-bit Windows runs 32-bit applications FASTER than those applications run on 32-bit Windows. Lacking the need for a larger virtual address space, there is absolutely no compelling need to re-write 32-bit application code to become 64-bit application code at this point. Will it EVENTUALLY happen? Sure. But this isn't like the 16-bit to 32-bit transition where almost EVERYONE needed the extra address space. Or the (cursed) x86 to IA64 move, where you have to upgrade or the performance of your app sucks due to translation and unaligned access issues. No. Because 64-bit Windows on the x64 is DESIGNED to allow 32-bit apps to happily co-exist.

    In terms of "ugly hacks"... in whose eyes? I'm sure Mom and Dad don't know -- or care -- what the SysWow32 directory is, or that there are 64-bit executables in the System32 directory. I bet they don't even know that there ARE 64-bit executables or what the "32" in System32 refers to. To them, and in fact to any sane user, System32 is the system after System31 and the one before System33. In fact, *I* don't even care. Why should I?

    Insert program, run program, program works... user gets work accomplished without annoyance. Done. Full stop.

    Ahhhh... different strokes, I guess.

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,004
    Joseph M. Newcomer wrote:
    >
    >
    >
    > The whole point of the IA-64 architecture was that you would not have
    > to devote acres of silicon to producing the illusion of a synchronous
    > CISC architecture on top of an asynchronous RISC architecture. I knew
    > it was doomed the moment I read the statement that “the compiler will
    > optimize the concurrency”. I had a student, back when I was
    > University faculty, who worked on optimizing horizontal microcode to
    > maximize concurrency. Essentially, what you get is the NP-hard “bin
    > packing problem”.
    >

    It's true that this is a hard problem, but that doesn't necessarily
    "doom" a processor. The Philips/NXP/Trident Trimedia, for example, is a
    VLIW processor with 5 slots per instruction, in which you can schedule a
    dozen functional units. The compiler manages all of the latencies and
    knows all of the dependencies. It takes a pretty freakin' smart
    compiler to handle that, but once you have a team that understands what
    they're doing, you can do amazing things. memcpy, for example, compiles
    to two instructions.

    Now, I'll grant that the Trimedia has so far survived only in a niche
    (although a large niche -- odds are the set top box from your satellite
    or cable company has a Trimedia in it), so maybe your assessment is not
    so far off.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • anton_bassovanton_bassov Member Posts: 5,008
    > I think I was being generous to Linux, frankly. OK, maybe you could convince me that Linux
    > supports 20% of the devices that Windows support... but I think that's seriously pushing it.
    > Now... I'm not talking about servers. I'm talking about devices supported AS A WHOLE..


    First of all, let's decide what "Linux" and "Windows" are in this context. I would propose that "Linux" is the latest source tree available from kernel.org, and "Windows" is the latest RTM version. At this point we will be able to quantify things - we will be able to compare vendor/device ID in Linux sources and in .inf files on the Windows CD. Are you ready for that or you would prefer to make ridiculous statements without any backup whatsoever.........


    Anton Bassov
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,262
    Anton,

    Which part of

    <QUOTE>
    if there's any more to be said about this -- it needs to go to NTTalk
    </QUOTE>

    was unclear to you?

    The part that included "any more to be said" in which I meant "said" as a sort of analogy, and didn't mean it to actual pertain only to SPEECH, but rather intended to convent that my comment applied to any additional follow-ups of any type (via forum, email, or NNTP)...

    the part about "this" meaning that my request applied to the discussion about x64 versus x86...

    or the part about "it needs to go to NTTALK", where once again I didn't mean the actual POST should -- of its own power -- move to the other news group, but rather I intended this to imply that further replies should be posted to a different group, and not this one.

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,306
    That would be the box that, on the order of once per week, performs the
    belly button stare followed by manual power intervention?

    I agree that within the confines of a restricted programming environment
    some smart people might get the compiler right. All bets are off on a
    general purpose system.

    Mark Roddy


    On Tue, Apr 6, 2010 at 5:38 PM, Tim Roberts wrote:

    >
    > Now, I'll grant that the Trimedia has so far survived only in a niche
    > (although a large niche -- odds are the set top box from your satellite
    > or cable company has a Trimedia in it), so maybe your assessment is not
    > so far off.
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,306
    Plus I should read the other messages before violating edicts. Sorry, over
    and out.

    Mark Roddy


    On Wed, Apr 7, 2010 at 9:28 AM, Mark Roddy wrote:

    > That would be the box that, on the order of once per week, performs the
    > belly button stare followed by manual power intervention?
    >
    > I agree that within the confines of a restricted programming environment
    > some smart people might get the compiler right. All bets are off on a
    > general purpose system.
    >
    > Mark Roddy
    >
    >
    > On Tue, Apr 6, 2010 at 5:38 PM, Tim Roberts wrote:
    >
    >>
    >> Now, I'll grant that the Trimedia has so far survived only in a niche
    >> (although a large niche -- odds are the set top box from your satellite
    >> or cable company has a Trimedia in it), so maybe your assessment is not
    >> so far off.
    >
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    On Tue, Apr 06, 2010 at 10:14:15AM -0400, xxxxx@osr.com wrote:
    > THIRD, *the* limiting problem for x64 has always been driver support.
    > Linux systems don't support one TENTH of the devices supported by
    > Windows.

    Just a small note to correct this inaccurate statement. Linux actually
    supports more devices than any other operating system, including
    Windows. It has been this way for quite a number of years, and this
    fact has been independantly verified by Microsoft itself (off-the-record
    of course.)

    thanks,

    greg k-h
  • Ahmad_HamadAhmad_Hamad Member Posts: 18
    Great note Greg :),

    <QUOTE>
    we all know Linux sucks, right (at least I do).
    </QUOTE>
    Aram, I like the level of abstraction that the linux kernel has and I like the stability that FreeBSD has.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,262
    <QUOTE>
    Just a small note to correct this inaccurate statement. Linux actually
    supports more devices than any other operating system
    </QUOTE>

    Only if you count TiVo and mass spectrometers and other similar instruments.

    But next time I try to get my multi-monitor Nvidia system, or my laptop with a wifi card, doing something useful... I'll certainly think of how great the device support is on Linux.

    Clearly, we'll just have to agree to disagree on this one...

    Peter
    OSR

    Peter Viscarola
    OSR
    @OSRDrivers

  • Gregory_G._DyessGregory_G._Dyess Member - All Emails Posts: 369
    Well, just one data point....If you read and follow the instructions
    exactly, getting dual monitors to work (very well) under Ubuntu Linux on my
    quad-core was a piece of cake for me and I am NOT a Linux guru by any
    stretch. I also had no problems with ALL of the hardware (WiFi, touch
    buttons, etc) on my HP dv6120 with plain vanilla ubuntu. It wasn't until
    Windows 7 did that work without a ton of special drivers from HP. My
    ExpressCard eSATA adapter worked out of the box with Ubuntu and I had to go
    get special drivers for Windows 7 from the manufacture's web site.

    Having used and abused both, my experience is that Linux supports mainstream
    hardware far better than Windows.


    Greg (not the same one)

    -----Original Message-----
    From: xxxxx@lists.osr.com
    [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
    Sent: Monday, April 12, 2010 9:13 AM
    To: Windows System Software Devs Interest List
    Subject: RE:[ntdev] A long overdue demise

    <QUOTE>
    Just a small note to correct this inaccurate statement. Linux actually
    supports more devices than any other operating system
    </QUOTE>

    Only if you count TiVo and mass spectrometers and other similar instruments.

    But next time I try to get my multi-monitor Nvidia system, or my laptop with
    a wifi card, doing something useful... I'll certainly think of how great the
    device support is on Linux.

    Clearly, we'll just have to agree to disagree on this one...

    Peter
    OSR




    ---
    NTDEV is sponsored by OSR

    For our schedule of WDF, WDM, debugging and other seminars visit:
    http://www.osr.com/seminars

    To unsubscribe, visit the List Server section of OSR Online at
    http://www.osronline.com/page.cfm?name=ListServer
  • anton_bassovanton_bassov Member Posts: 5,008
    Guys,

    Actually, we are already discussing it with Peter and few other participants on NTTALK - you can check our argumentation there....


    Anton Bassov
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    On Mon, Apr 12, 2010 at 10:12:30AM -0400, xxxxx@osr.com wrote:
    > <QUOTE>
    > Just a small note to correct this inaccurate statement. Linux actually
    > supports more devices than any other operating system
    > </QUOTE>
    >
    > Only if you count TiVo and mass spectrometers and other similar instruments.

    I'm curious as to why you would not consider those valid devices? Are
    they not valid platforms to support?

    > But next time I try to get my multi-monitor Nvidia system, or my
    > laptop with a wifi card, doing something useful... I'll certainly
    > think of how great the device support is on Linux.

    I have multi-monitor systems working as well as every wifi device
    currently known, working just fine "out of the box" today.

    Seriously, the "there is no drivers for Linux" myth was disproven a long
    time ago, please don't perpetuate it.

    > Clearly, we'll just have to agree to disagree on this one...

    Clearly :)

    thanks,

    greg k-h
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA