You're right. It was the R3000. I got the order confused. And don't forget the Fairchild - later Intergraph - Clipper. It was in the first tier of ports as well.
I think you're off by a year on the Alpha 64 port. I remember it starting in '95 (about the same time the PowerPC port being done over at Carrilon Point was stalled while IBM and Apple argued over whether the CHRP platform ABSOLUTELY MUST or ABSOLUTELY MUST NOT support a parallel port) but that's based on memories of what building I was in so that may be hazy.
Actually, Microsoft has three 64-bit versions of Windows that are released and supported and four more in beta. Here's what's available:
Released 64-bit versions of Microsoft Windows
Windows Server 2003 for 64-Bit Itanium-based Systems - Enterprise Edition
Windows Server 2003 for 64-Bit Itanium-based Systems - Datacenter Edition
Windows XP 64-bit Edition (Itanium)
Beta 64-bit versions of Microsoft Windows
Windows Server 2003 for 64-Bit Itanium-based Systems - Standard Edition
Windows Server 2003 for 64-Bit Extended Systems - Standard Edition
Windows Server 2003 for 64-Bit Extended Systems - Enterprise Edition
Windows XP 64-Bit Edition for 64-Bit Extended Systems
All of this blather is about "Windows XP 64-Bit Edition for 64-Bit Extended Systems" and is, of course, ignoring the other six versions including a released and supported Windows XP 64-bit Edition for the Itanium family.
Microsoft has to hunt down every pointer in their windows code, which is vast.
Been there. Done that. Or did you think the Win64 Itanium port didn't already flush all that out. As for the "Vast" number of version specific pointers, glad you have an opinion of the internal code in an OS when you don't even realize that it's been ported for 64-bit for a LONG TIME now.
Exactly. Windows XP is a CONSUMER OS and needs to ship with a full set of drivers. Server OS releases like Windows Server 2003 can ship with limited driver support but not the OS for novices. (Hopefully, all the "Windows isn't architected to be ported" idiots will notice that 64-bit Windows has been out for years for Itanium and didn't take that long to port. And if they think AMD's 64-bit architecture is harder to port to from x86 than Itanium then they really know nothing about chip architectures)
Just as an FYI, Windows NT's internal architecture has been 64-bit since it was designed back in the late '80s. The 32-bit releases are downward ports. Dave Cutler's not an idiot. (Oh, and before anybody starts talking about 32-bit'isms in Win32, realize that Win32 is a layer on top of Windows NT and isn't the native OS interface)
Um. Hate to break it to you but Windows NT 3.1 shipped in 1993 with versions for x86, Alpha and MIPS. (That's 11 years ago for the arithmetically challenged) It later was ported to Clipper and PowerPC.
They actually switched native development from the i860 to the DEC Alpha. The x86 version was actually a port. Cutler wanted to make sure that the MS developers didn't slip in any x86 specific code so he had the team write the OS on a relatively unfamiliar platform and port to the one they knew best.
Windows NT (and family) have shipped in x86, Alpha, Clipper, PowerPC and were ported to several other chips as tests.
It's also worth noting that the Windows API is NOT native to the Windows NT family and another API could be dropped in as needed. Early versions shipped with OS/2 and Posix.1 native support as well as Win32. (And, no, these are not emulators or porting layers on top of a native API, they're just as native as Win32)
Win32s, for example was a porting layer to run a subset (hence the s) of the Win32 32-bit APIs on Win16 Operating Systems. (0% 32-bit by definition)
Windows 95 was a 32-bit OS with 16-bit loadable sections for backward compatibility. If you didn't run 16-bit drivers or apps, you didn't have 16-bit.
The Windows NT family (Windows NT, Windows 2000, Windows XP, Windows Server 2003) were written from the start as 32-bit/64-bit hybrids with their architecture at 64-bit and their APIs and implementation ported down to 32-bit.
Oh, and OS/2 was originally a 16-bit OS and was gradually ported to 32-bit starting with 3.x.(Perhaps you never bothered to look at OS/2 1.x or 2.x which didn't even support the 386 extensions to the intel 16-bit architecture but my guess is that you never really used OS/2 but just heard it wasn't a MS OS so it's really kewl to discuss it, d00d)
MS historically is not that good at portability. NT on powerpc, alpha, mips(maybe) failed.
Um. Hate to break it to you but MS produced very good ports of Windows NT to Intel x86, PowerPC, MIPS and Clipper. (As a bit of trivia, NT was originally written on Alpha and ported to x86 to make sure that the mostly x86 developers didn't include any Intelisms in the code). NT was written from the start to be portable.
The fact that IBM, Apple, DEC, Intergraph, etc couldn't get their acts together to actually sell any hardware didn't mean MS didn't get really solit ports done.
Microsoft's UI guidelines have been around for a very long time. When I wrote the first public course on Visual Basic programming for Microsoft over 13 years ago, I included a 2 hour long module to explain to developers exactly how to use the UI guidelines with labs to show how following them made for a better app.
Ctrl-A - All
Ctrl-B - Bold
Ctrl-C - Copy
Ctrl-F - Find
Ctrl-I - Italics
Ctrl-N - New
Ctrl-O - Open
Ctrl-P - Print
Ctrl-S - Save
Ctrl-U - Underline
Ctrl-V - paste
Ctrl-X - cut
Ctrl-Y - redo
Ctrl-Z - undo
Sorry about Ctrl V-Z not being mnemonic, they were copied from MacWord so that they'd be the same across all Microsoft platforms.
Yes, there are also shortcuts available on the Alt key and the Function keys. (as there are on the cloverleaf and Function keys for Apple)
As for you not knowing where the options are on a Windows app, they've been on the "Tools" menu for many years. Of course, some apps don't follow the UI rules but that isn't because Microsoft hasn't told the developers what to do, it's because the developers have a "better idea" than the standard UI. Exactly what this discussion is about.
As for the dock coming from NeXT, the idea of a group of Icons for running programs was present in Windows 1.0x from 1985 - long before Stevie started up NeXT to piss off the Apple people who ousted him from his own company. The idea of a group of always-accessable icons for commonly used shortcuts in an area of the screen not covered by a maximized window is NOT the NeXT tray. Sorry - that's Windows again.
Yep. There's a lot of UI tweaking in XP but most of it is subtle (as most good UI tweaks are)
Of course, the person earlier in this discussion who gave us all the detailed steps he takes to "fix" the Windows XP UI turned a lot of them off because they were, apparently, too frightened by change. So, the problem isn't just with novice users...
And just to be thorough, neither Mac nor Windows Maximizes to an intermediate size. The maximize to the maximum size. They both restore to an intermediate state.
Nope. I'm guessing you really haven't used Windows in a while and never really did learn it. For example. Windows XP puts, by default, exactly ONE icon on the desktop. The recycle bin. That's it. Everything else goes on the Start menu (always accessable) or the Quick Start bar on the Taskbar (always accessable and copied by Apple to be the "Dock")
Microsoft DOES have standard shortcuts in Windows and has for a decade or so.
Perhaps you should actually try using Windows before telling the rest of us how it works.
Just an FYI, Virtual Desktops on PCs predate Linux by at least a decade. Just because your favorite product has a feature doesn't mean they invented it.
Actually, the Windows "Start" button does extend all the way to the lower left corner (by default).
As for the loss of speed by having multiple single menus per window rather than one contextually switching menu at the top, there's also data showing that the change in context costs users time as well. That one's not exactly as ideal as Mac fans claim.
Nonsense. Improv wasn't innovative in any sense of the word. Lotus Improv was nothing but a GUI port of Javelin.
Now Javelin was innovative, basically an OLAP spreadsheet that was like nothing else on the market when it came out. Lotus cloning it (and then killing their clone) shouldn't get anybody's praise.
The original design for the Zilog Z-80000 (Not to be confused with the Z80000 that actually shipped and was an enhanced Z8001) was also dynamically self configuring and optimized its execution based on the frequency of use of instructions.
Of course, that was only a little over 20 years ago.
FYI: Since somebody is going to ask... The original Z80000 design was killed when Zilog stalled out as a general purpose processor maker and moved into embedded processors after the bugs in the initial run of Z8001 chips and IBM's selection of the Intel 8088.
Guys, it's time to face the facts. C is a relic from a time when compilers were stupid.
Nah. C is a relic of a quick and dirty PDP assembler thrown together with no intention of making a really serious language and designed to deal with a limited set of problems. When C came out, it had been years since compilers had been that stupid.
I mean, really folks, look at any history of computer languages and you won't see a design that stupid since the early 1960s.
A Linux UI that's slightly better at exactly copying Microsoft's designs than all the other common Linux UI's that are also almost exact copies of Microsoft's designs.
Wow. Innovation from the Open Source community at last...
REXX certainly shouldn't be on the forefront of modern computing but tragically still is since the popularization of that 1960 throwback language C crippled the programming language industry 20 years ago and led to thhe requirement that all "innovations" be built on top of a language that has less string handling than FORTRAN and all the friendliness of a bad assembler.
Seriously, anybody who hasn't worked with REXX has no clue what a scripting language could be or just how badly the industry was crippled by the C popularization.
As an added detail on REXX's history, it was written by Mike Cowlishaw (known as mfc internally) as a spare time project because the EXEC and EXEC2 scripting languages for VM sucked so badly. It was so useful that it spread through IBM's internal VMTOOLS forum until so much was dependant on it that it became the standard for VM/CMS scripting and IBM had to make it official because nobody was willing to use the "official" scripting languages including their customers.
Last I'd heard, mfc was supporting it internally and maintaining the IBMJARGON dictionary of internal jargon but that was 15 years ago.
Slashdot Mirror
I think you're off by a year on the Alpha 64 port. I remember it starting in '95 (about the same time the PowerPC port being done over at Carrilon Point was stalled while IBM and Apple argued over whether the CHRP platform ABSOLUTELY MUST or ABSOLUTELY MUST NOT support a parallel port) but that's based on memories of what building I was in so that may be hazy.
It makes all the "Windows is hard to port" or "Windows is 32-bit" blather pretty obviously an expression of total ignorance.
Released 64-bit versions of Microsoft Windows
- Windows Server 2003 for 64-Bit Itanium-based Systems - Enterprise Edition
- Windows Server 2003 for 64-Bit Itanium-based Systems - Datacenter Edition
- Windows XP 64-bit Edition (Itanium)
Beta 64-bit versions of Microsoft Windows- Windows Server 2003 for 64-Bit Itanium-based Systems - Standard Edition
- Windows Server 2003 for 64-Bit Extended Systems - Standard Edition
- Windows Server 2003 for 64-Bit Extended Systems - Enterprise Edition
- Windows XP 64-Bit Edition for 64-Bit Extended Systems
All of this blather is about "Windows XP 64-Bit Edition for 64-Bit Extended Systems" and is, of course, ignoring the other six versions including a released and supported Windows XP 64-bit Edition for the Itanium family.Nope. Windows 98 and Windows ME are direct descendants of Windows 95 but none of them are direct descendants of Windows 3.xx. Thanks for playing.
Been there. Done that. Or did you think the Win64 Itanium port didn't already flush all that out. As for the "Vast" number of version specific pointers, glad you have an opinion of the internal code in an OS when you don't even realize that it's been ported for 64-bit for a LONG TIME now.
Exactly. Windows XP is a CONSUMER OS and needs to ship with a full set of drivers. Server OS releases like Windows Server 2003 can ship with limited driver support but not the OS for novices. (Hopefully, all the "Windows isn't architected to be ported" idiots will notice that 64-bit Windows has been out for years for Itanium and didn't take that long to port. And if they think AMD's 64-bit architecture is harder to port to from x86 than Itanium then they really know nothing about chip architectures)
Just as an FYI, Windows NT's internal architecture has been 64-bit since it was designed back in the late '80s. The 32-bit releases are downward ports. Dave Cutler's not an idiot. (Oh, and before anybody starts talking about 32-bit'isms in Win32, realize that Win32 is a layer on top of Windows NT and isn't the native OS interface)
Um. Hate to break it to you but Windows NT 3.1 shipped in 1993 with versions for x86, Alpha and MIPS. (That's 11 years ago for the arithmetically challenged) It later was ported to Clipper and PowerPC.
Windows NT (and family) have shipped in x86, Alpha, Clipper, PowerPC and were ported to several other chips as tests.
It's also worth noting that the Windows API is NOT native to the Windows NT family and another API could be dropped in as needed. Early versions shipped with OS/2 and Posix.1 native support as well as Win32. (And, no, these are not emulators or porting layers on top of a native API, they're just as native as Win32)
Win32s, for example was a porting layer to run a subset (hence the s) of the Win32 32-bit APIs on Win16 Operating Systems. (0% 32-bit by definition)
Windows 95 was a 32-bit OS with 16-bit loadable sections for backward compatibility. If you didn't run 16-bit drivers or apps, you didn't have 16-bit.
The Windows NT family (Windows NT, Windows 2000, Windows XP, Windows Server 2003) were written from the start as 32-bit/64-bit hybrids with their architecture at 64-bit and their APIs and implementation ported down to 32-bit.
Oh, and OS/2 was originally a 16-bit OS and was gradually ported to 32-bit starting with 3.x.(Perhaps you never bothered to look at OS/2 1.x or 2.x which didn't even support the 386 extensions to the intel 16-bit architecture but my guess is that you never really used OS/2 but just heard it wasn't a MS OS so it's really kewl to discuss it, d00d)
Um. Hate to break it to you but MS produced very good ports of Windows NT to Intel x86, PowerPC, MIPS and Clipper. (As a bit of trivia, NT was originally written on Alpha and ported to x86 to make sure that the mostly x86 developers didn't include any Intelisms in the code). NT was written from the start to be portable.
The fact that IBM, Apple, DEC, Intergraph, etc couldn't get their acts together to actually sell any hardware didn't mean MS didn't get really solit ports done.
- Ctrl-A - All
- Ctrl-B - Bold
- Ctrl-C - Copy
- Ctrl-F - Find
- Ctrl-I - Italics
- Ctrl-N - New
- Ctrl-O - Open
- Ctrl-P - Print
- Ctrl-S - Save
- Ctrl-U - Underline
- Ctrl-V - paste
- Ctrl-X - cut
- Ctrl-Y - redo
- Ctrl-Z - undo
Sorry about Ctrl V-Z not being mnemonic, they were copied from MacWord so that they'd be the same across all Microsoft platforms.Yes, there are also shortcuts available on the Alt key and the Function keys. (as there are on the cloverleaf and Function keys for Apple)
As for you not knowing where the options are on a Windows app, they've been on the "Tools" menu for many years. Of course, some apps don't follow the UI rules but that isn't because Microsoft hasn't told the developers what to do, it's because the developers have a "better idea" than the standard UI. Exactly what this discussion is about.
As for the dock coming from NeXT, the idea of a group of Icons for running programs was present in Windows 1.0x from 1985 - long before Stevie started up NeXT to piss off the Apple people who ousted him from his own company. The idea of a group of always-accessable icons for commonly used shortcuts in an area of the screen not covered by a maximized window is NOT the NeXT tray. Sorry - that's Windows again.
Of course, the person earlier in this discussion who gave us all the detailed steps he takes to "fix" the Windows XP UI turned a lot of them off because they were, apparently, too frightened by change. So, the problem isn't just with novice users...
And just to be thorough, neither Mac nor Windows Maximizes to an intermediate size. The maximize to the maximum size. They both restore to an intermediate state.
Microsoft DOES have standard shortcuts in Windows and has for a decade or so.
Perhaps you should actually try using Windows before telling the rest of us how it works.
Just an FYI, Virtual Desktops on PCs predate Linux by at least a decade. Just because your favorite product has a feature doesn't mean they invented it.
As for the loss of speed by having multiple single menus per window rather than one contextually switching menu at the top, there's also data showing that the change in context costs users time as well. That one's not exactly as ideal as Mac fans claim.
Bravo. Finally an intelligent post!
Nonsense. Improv wasn't innovative in any sense of the word. Lotus Improv was nothing but a GUI port of Javelin. Now Javelin was innovative, basically an OLAP spreadsheet that was like nothing else on the market when it came out. Lotus cloning it (and then killing their clone) shouldn't get anybody's praise.
Of course, that was only a little over 20 years ago.
FYI: Since somebody is going to ask... The original Z80000 design was killed when Zilog stalled out as a general purpose processor maker and moved into embedded processors after the bugs in the initial run of Z8001 chips and IBM's selection of the Intel 8088.
Nah. C is a relic of a quick and dirty PDP assembler thrown together with no intention of making a really serious language and designed to deal with a limited set of problems. When C came out, it had been years since compilers had been that stupid.
I mean, really folks, look at any history of computer languages and you won't see a design that stupid since the early 1960s.
Well, Visual PL/I would be one easy way to fix all those C buffer overrun errors and idiotic syntax, um, quirks. Count me in.
A Linux UI that's slightly better at exactly copying Microsoft's designs than all the other common Linux UI's that are also almost exact copies of Microsoft's designs.
Wow. Innovation from the Open Source community at last...
Don't forget the amazing
PARSE PULL
Ah, what a wonderful command...
REXX certainly shouldn't be on the forefront of modern computing but tragically still is since the popularization of that 1960 throwback language C crippled the programming language industry 20 years ago and led to thhe requirement that all "innovations" be built on top of a language that has less string handling than FORTRAN and all the friendliness of a bad assembler.
Seriously, anybody who hasn't worked with REXX has no clue what a scripting language could be or just how badly the industry was crippled by the C popularization.
As an added detail on REXX's history, it was written by Mike Cowlishaw (known as mfc internally) as a spare time project because the EXEC and EXEC2 scripting languages for VM sucked so badly. It was so useful that it spread through IBM's internal VMTOOLS forum until so much was dependant on it that it became the standard for VM/CMS scripting and IBM had to make it official because nobody was willing to use the "official" scripting languages including their customers.
Last I'd heard, mfc was supporting it internally and maintaining the IBMJARGON dictionary of internal jargon but that was 15 years ago.