Future versions of OS X will likely further reduce the differences between the two flavors, and make it even easier to design a single application that runs, without changes, in either a touch-based or mouse-based environment. With proper design, it's already really easy to separate out your UI and core functionality such that you can create an iPhone and a Mac application from the same sources.
Yes, it would be nice if you could design a single application that runs, without changes, on a 480x360 pixel 3.5 inch screen and a 1280x800 pixel 13.3 inch screen.
That's the real issue that I see, not touch vs. mouse; a UI that works well on a desktop or notebook screen might really suck on a smaller screen - that's why a lot of Web sites offer "regular" and "mobile" versions, for example.
You might end up with the core functionality being common but the UI code not being common; you really might have to design two separate UIs in order not to have a UI that sucks on one of the two platforms or a UI that half-sucks on both platforms.
that will only happen if the Macbook and the iPhone merge to a common processor. Until then, the binaries will not be compatible with each other, so the same app on one will not run on the other, without some sort of emulation, but that eats into performance.
Yeah, because, as we all know, Mac OS X runs only on x86 and x86-64 processors; it's not as if, say, Apple switched Macs from using PowerPC processors to x86/x86-64 processors and offered some scheme to support "fat binaries" that would run on Macs with PPC processors and Macs with x86 processors, with both types of binary code in the same file....
No, some Apple apps are allowed to stay in memory (and run) whereas no third party apps are given the privilege. Mail will download emails in the background for instance, and Safari maintains your open tabs.
Safari isn't guaranteed to maintain your back button/forward button history, however; sometimes it loses them.
Your open tabs are kept in stable storage, so they survive Safari shutting down and being restarted. The same is true of newer versions of Safari on Mac OS X, although you have to use History->Reopen All Windows From Last Session after restarting Safari.
Your back button/forward button history isn't maintained in stable storage (whether in Mac OS X or iPhone OS), and that gets lost if Safari is restarted.
And, yes, Safari on the phone will be killed off in the background on occasion; I've had that happen on occasion when switching to Mail, for example.
So in other words, AT&T has to make it as useless as possible, so Apple would have been better off just not having it...
...because AT&T is the only carrier anywhere in the world on which the iPhone runs, of course. If it sucks in the US, that doesn't necessarily mean it'll suck everywhere.
I've seen reports of people trying this using QEMU under zSeries Linux, under zVM. Wouldn't surprise me if that's about all the Mantissa product is:
Something like QEMU natively compiled under CMS.
QEMU supports binary-to-binary translation; does that include translation of x86 instructions to z/Architecture instructions? If not, then
that might explain the slowness in the reports you've seen;
the Mantissa product is probably not like QEMU in that respect.
The funny part is that (very deep) under the covers, the zSeries processor is a modified PowerPC running microcode. I think I'll wait for IBM
to develop x86 microcode
Don't hold your breath waiting. As other replies (and the IBM paper cited in one of those replies) note, the processor is a cousin of POWER6, but is not a "modified PowerPC" - it's designed to execute z/Architecture instructions, not PPC instructions, and executes the simpler ones in hardware and the more complicated ones in "millicode", which is z/Architecture code running in a special mode that gives it access to additional machine resources (special GPRs, etc.) and, as I remember, some special insstructions (for those familiar with DEC's Alpha, think "PALcode").
VMS did not eventually ship on the machine it began being designed for (PDP-11 for VMS, i860 for NT).
VMS - not RSX-11M - was originally designed for the PDP-11? Citation?
The impression I had was that NT was designed to be portable, and that the work was done on the i860 to make sure people didn't fall into the "all the world's an 80386" trap, but it was intended to run on the x86 as well.
z/Architecture - and, I think, later if not all versions of S/390 - include instructions to do IEEE binary floating point as well as IBM floating point.
hah In all due fairness though I agree, alot of greed and artificial isolation to specific hardware for sales purposes were done in the past with Sun and various other manufacturers.
SunOS 4.x, back in the late '80's, ran on three different instruction set architectures (68k, SPARC, i386) with a reasonably good design for portability (e.g., most of the work of dealing with the MMU was isolated in a layer with MMU-dependent implementations of standard APIs used by the rest of the VM code), and there was a never-released port to S/3xx as well.
NT kernel infrastructure was made by an ex-VMS guy, so that's probably why.
VMS was, I think, rather VAX-oriented in the lower layers, so, unless the idea was that Cutler knew what not to do from his VMS experience, I'm not sure that was the reason why NT was designed for portability. It might more have been that he was an ex-Mica guy, although that was somewhat Prism-oriented.
Windows NT has run on i860, x86, Mips, PowerPC, Alpha and Itanium. And many more if you include Windows CE
As far as I know, NT and CE are different code bases, although there might be some shared code in some layers.
Xbox, etc.
And is, I think, a PowerPC variant, so it's not as if they ported it to a completely different architecture.
But, yes, it might be possible to port NT to S/3xx or z/Architecture. The unprivileged part of the instruction set should be easy; the privileged part might be some more work - the hard part would probably be the I/O architecture, but, heck, if Linux can do it, NT can probably do it, too. ("NT" here refers to anything using that line of code bases, hence everything up to Vista, Server 2008, Windows 7.)
Some of the mainframes in question are apparently built out of "Intel" processors (presumably either x86-64 or Itanium); the others appear to have proprietary Unisys chips implementing the 36-bit Univac 11xx architecture but probably also have Intel chips to run Windows. What's impressive about those is that they're apparently running the old OS for the 36-bit Univac processors on the Intel systems ("This revolutionary server features the OS 2200 operating system running on Intel(R) processors"), which probably involved at least as much work (probably via binary-to-binary translation + instruction interpretation) as the stuff the people at Mantissa have done (also probably via binary-to-binary translation + instruction interpretation, but the Mantissa people are presumably just emulating one 8-bit-byte-oriented architecture on another, not emulating a 36-bit word-oriented architecture on an 8-bit-byte-oriented architecture).
IBM was pushing Windows NT 3.51 on the mainframe back in the 1990's.
Hitachi != IBM, and DEC != IBM. The original article says:
Hitachi and Digital Equipment (DEC ) today announced that they are cooperating on software technology that will move the Windows NT operating system onto mainframe-class computers, another sign that Microsoft's most powerful operating system is set to move deep into high-end computing territory.
The joint work on server systems using either Intel or Alpha processors signals an ongoing decentralization of computing power from the once almighty mainframe.
so they were not talking about NT on S/3xx - they were talking about NT on Intel (probably Itanium, possibly x86) and Alpha, all of which I think existed at the time.
How about actually recompiling Windows into native code running on that mainframe. Now that would be impressive. Especially if it was big endian, and with unusual word sizes,
I don't think you'll get anything from IBM these days with what people would generally consider "unusual word sizes", unless they still have a few 709x's in a warehouse from the late '50's or early '60's. S/3xx was, from Day One, a 32-bit-word (originally with only 24 bits of that used in addressing, then with an option to expand to 31 bits), 8-bit-byte-addressible architecture long before the 80386 existed.
Big-endian might be more work, although I think that, for example, Connectix's/Microsoft's Virtual PC for Mac did both interpretation and binary-to-binary translation of x86 code to PPC code.
Maybe it you try to follow a NULL pointer you end up at uninitialzed memmroy. eg printf("hello %x", *NULL);
If you try to follow a null pointer on any Win32 (or presumably Win64) environment, at least the ones from Microsoft (and probably in WINE and ReactOS as well), you end up at a page mapped out of your address space, and probably get a trap/fault/signal/exception, just as you do on most versions of UN*X - at least as long as the offset from that pointer to which you're referring isn't large enough that you get past the end of the unmapped region. Most structures are probably small enough that you'll refer to the unmapped region; I guess if you have a pointer to a large-enough array and use a large-enough array index you could end up in a mapped region, although that'll probably be a read-only code region so you might still get a fault if you store into that region. (I don't know offhand how address space randomization would affect that.)
So, basically, it only has arrays in the sense the standard calls them "arrays", even though it also admits that they're actually pointers.
No. It has arrays in the sense that
if you declare int foo[3];, the memory allocated for that is 3 ints and no int *'s;
you can declare a pointer of type "pointer to {type}[N]", and, for example, have a function whose argument is "pointer to int[3]", and, if you pass that function a "pointer to int", or "pointer to int[2]", that will be a type mismatch (yes, I've actually used that feature, to make sure a function wasn't passed an undersized array).
It doesn't have arrays in the sense that you can assign arrays or pass them, rather than pointers to them, or pointers to non-array elements of them, to functions, or return them from functions.
So, no, they're not "actually pointers"; they're more like structures were in the old days of C, before you could assign structures, pass them as arguments, or return them from functions.
All modern C implementations use null terminated strings,
All implementations of C use or used null-terminated strings, as that's part of the language; it's not a characteristic of the implementation.
(actually, it's technically a pointer - C doesn't have real arrays)
Yes, it does have real arrays. In expressions, "array-valued" expressions are converted to "pointer-valued" expressions that point to the first element of the array (ANSI X3.159-1989, section 3.2.2.1 "Lvalues and Function Designators", 3rd paragraph).
No, it represents a null pointer as an all-bits-zero value, as do almost all other C implementations.
But then you have to code:
No, you don't. In the C Programming Language, if p is a pointer, then !p, p != 0, and p != NULL mean the same thing, regardless of how null pointers are represented.
Not at all. You're not testing a pointer, you're testing a boolean value. If the type casting is smart enough to check for NULL instead of 0 when converting a pointer to a bool, if(p) will work just fine.
Well, not exactly. If we're talking C, there's no notion of a "boolean" expression; the part of C that makes it work is that:
!p means the same thing as p != 0;
0, when used to assign to or compare with a pointer, is not the integral constant 0, it's the "null pointer constant", which is a constant pointer value that is unequal to the address of any C object.
No, GP is correct. If the compiler knows the contents at address zero, and that it's not equal to CONSTANT, the optimization gives the same answer. It's a peep-hole optimization level thing.
No, the poster in question is incorrect. If a particular implementation of C happens to represent the null pointer constant in a fashion that makes it look like a pointer to location X, then the C compiler is obliged to arrange that no object live at that location, so, in this particular case, the contents at address zero are irrelevant.
Not sure if iTunes for Windows and its "Apple Update" feature is the same as the version of "Software Update" for OSX?
It's not. There may be some shard code or concepts, but "Software Update" for OS X is more like "Windows Update" for Windows, possibly with the added capability of updating Apple software that's not part of OS X (dunno if Windows Update will, for example, download and install any updates to Office that are free).
I would be willing to guess that Safari was already on your OSX MBP
Given that it's Apple's own browser and that OS X ships with a browser, yes, it is.
and perhaps the MBP 'Software updater' and/or the iTunes 'Apple Updater' did not upgrade your version of Safari automatically
No, it didn't. It offers you upgrades, but doesn't (at least by default) force them on you itself. (Sometimes when you upgrade one piece of software you have to upgrade others, e.g. you might think an iTunes upgrade won't require a reboot, but sometimes it turns out to require a QuickTime update in order to play videos again, and that will require a reboot.)
I like OSX too
Assuming you're not just trolling, you mustn't have used it recently, or mustn't have used it much, or you'd know that Safari comes with OS X as its built-in browser (similar to IE on Windows and Konqueror on OSes that come with KDE as the desktop environment) and that Software Update is an OS update feature and doesn't forcibly update software.
For example, in England if you can afford to pay for treatment you are free to do so, if you want to take out insurance to pay for treatment you are free to do so, if you want to use the National Health Service for your treatment you are free to do so.
That might not be the case in Canada. The trouble is that people criticizing "socialized medicine" sometimes pick particular characteristics of particular countries' health care systems and treat them as universal characteristics of all health care systems.
#1 ReactOS and HaikuOS can use a different file system than FAT.
So could the Linux that TomTom are using.
#2 The source code of the ReactOS and HaikuOS uses different techniques to access FAT volumes anyway.
Unless I'm missing something, the patent is about the on-disk format, not just the techniques to access the data stored in that format.
#3 Since ReactOS and HaikuOS are not as widely used as Linux, doubtful Microsoft will sue them as there is no money to be made doing so. TomTom on the other hand, earns money hand over fist and thus made themselves a target by Microsoft.
Please note this is not "suing Linux" but "Suing Tomtom" for using a Linux based solution that accesses FAT devices and stores an 8 lettered file name as a 32 filed one. Had Tomtom used Windows CE, doubtful Microsoft would have sued them.
As you note, this is "suing TomTom"; your argument appears to be that if TomTom were to use HaikuOS or ReactOS, they still would have been sued, in which case neither HaikuOS nor ReactOS would make issues like this go away.
Yes it is possible to access FAT volumes and not break any patents, and still leave them in a way that Microsoft's FAT implementation(s) can still read it. For example you can read it in the 8 character file name, as Apple's old operating systems used to do and ignore the 32 character file name.
Do the filesystems that TomTom are reading have files with long names on them? If so, then they risk infringing the patent. If not, then they could presumably just rip the VFAT stuff out of the file system code (or have somebody else do it) and get rid of their concerns for that patent.
Of course, that still leaves the patents unrelated to FAT....
If you hope that Haiku's or ReactOS's FAT implementation will somehow magically not infringe the two "long filename" patents when Linux's do, you hope in vain - the patent covers how stuff is written to storage, and if you do that differently form how (V)FAT does it, you might have an interesting file system, but you wouldn't have one that can handle stuff written so that Microsoft's FAT implementation(s) can read it.
With the possible exception of the flash file system patent, the other patent issues also wouldn't be alleviated by using a different OS.
So why would Haiku or ReactOS make issues such as this go away?
If by "safe" you mean "safe from the Microsoft patents in question", it's because NTFS was designed to support long file names, so there was no need to use a hack of the sort described by the two long filename patents to add support for long filenames in a backwards-compatible fashion. Perhaps other Microsoft patents cover NTFS, but the ones cited in the article don't.
The patents that are not car-GPS-specific have to deal with: short filenames
Actually, from a quick read, those two patents appear to deal with stuffing long filenames into a file system originally designed only to support short filenames, in a backwards-compatible fashion. Linux's FAT implementation does do that, so that it can read and write FAT file systems with long names.
The final issue is GUI objects. How MS got a patent on this one befuddles me. Obviously, Xerox/Parc beat them to this one. Why doesn't anyone overturn this patent?
Because it's not something so simple as a patent on "GUI objects"?
Slashdot Mirror
Future versions of OS X will likely further reduce the differences between the two flavors, and make it even easier to design a single application that runs, without changes, in either a touch-based or mouse-based environment. With proper design, it's already really easy to separate out your UI and core functionality such that you can create an iPhone and a Mac application from the same sources.
Yes, it would be nice if you could design a single application that runs, without changes, on a 480x360 pixel 3.5 inch screen and a 1280x800 pixel 13.3 inch screen.
That's the real issue that I see, not touch vs. mouse; a UI that works well on a desktop or notebook screen might really suck on a smaller screen - that's why a lot of Web sites offer "regular" and "mobile" versions, for example.
You might end up with the core functionality being common but the UI code not being common; you really might have to design two separate UIs in order not to have a UI that sucks on one of the two platforms or a UI that half-sucks on both platforms.
that will only happen if the Macbook and the iPhone merge to a common processor. Until then, the binaries will not be compatible with each other, so the same app on one will not run on the other, without some sort of emulation, but that eats into performance.
Yeah, because, as we all know, Mac OS X runs only on x86 and x86-64 processors; it's not as if, say, Apple switched Macs from using PowerPC processors to x86/x86-64 processors and offered some scheme to support "fat binaries" that would run on Macs with PPC processors and Macs with x86 processors, with both types of binary code in the same file....
No, some Apple apps are allowed to stay in memory (and run) whereas no third party apps are given the privilege. Mail will download emails in the background for instance, and Safari maintains your open tabs.
Safari isn't guaranteed to maintain your back button/forward button history, however; sometimes it loses them.
Your open tabs are kept in stable storage, so they survive Safari shutting down and being restarted. The same is true of newer versions of Safari on Mac OS X, although you have to use History->Reopen All Windows From Last Session after restarting Safari.
Your back button/forward button history isn't maintained in stable storage (whether in Mac OS X or iPhone OS), and that gets lost if Safari is restarted.
And, yes, Safari on the phone will be killed off in the background on occasion; I've had that happen on occasion when switching to Mail, for example.
So in other words, AT&T has to make it as useless as possible, so Apple would have been better off just not having it...
...because AT&T is the only carrier anywhere in the world on which the iPhone runs, of course. If it sucks in the US, that doesn't necessarily mean it'll suck everywhere.
I've seen reports of people trying this using QEMU under zSeries Linux, under zVM. Wouldn't surprise me if that's about all the Mantissa product is: Something like QEMU natively compiled under CMS.
QEMU supports binary-to-binary translation; does that include translation of x86 instructions to z/Architecture instructions? If not, then
The funny part is that (very deep) under the covers, the zSeries processor is a modified PowerPC running microcode. I think I'll wait for IBM to develop x86 microcode
Don't hold your breath waiting. As other replies (and the IBM paper cited in one of those replies) note, the processor is a cousin of POWER6, but is not a "modified PowerPC" - it's designed to execute z/Architecture instructions, not PPC instructions, and executes the simpler ones in hardware and the more complicated ones in "millicode", which is z/Architecture code running in a special mode that gives it access to additional machine resources (special GPRs, etc.) and, as I remember, some special insstructions (for those familiar with DEC's Alpha, think "PALcode").
VMS did not eventually ship on the machine it began being designed for (PDP-11 for VMS, i860 for NT).
VMS - not RSX-11M - was originally designed for the PDP-11? Citation?
The impression I had was that NT was designed to be portable, and that the work was done on the i860 to make sure people didn't fall into the "all the world's an 80386" trap, but it was intended to run on the x86 as well.
The second way is that mainframes have always been able to execute IEEE floating point in software,
Not before the mid '70's or so, at the earliest, they weren't - because IEEE floating point didn't exist before then. Work on the standard started in the mid '70's.
z/Architecture - and, I think, later if not all versions of S/390 - include instructions to do IEEE binary floating point as well as IBM floating point.
hah In all due fairness though I agree, alot of greed and artificial isolation to specific hardware for sales purposes were done in the past with Sun and various other manufacturers.
SunOS 4.x, back in the late '80's, ran on three different instruction set architectures (68k, SPARC, i386) with a reasonably good design for portability (e.g., most of the work of dealing with the MMU was isolated in a layer with MMU-dependent implementations of standard APIs used by the rest of the VM code), and there was a never-released port to S/3xx as well.
NT kernel infrastructure was made by an ex-VMS guy, so that's probably why.
VMS was, I think, rather VAX-oriented in the lower layers, so, unless the idea was that Cutler knew what not to do from his VMS experience, I'm not sure that was the reason why NT was designed for portability. It might more have been that he was an ex-Mica guy, although that was somewhat Prism-oriented.
Running x86 emulation on zArch is going to be slooooow.
Possibly, but it's probably done with a mix of interpretation and binary-to-binary translation, so it might not be too slow.
Windows NT has run on i860, x86, Mips, PowerPC, Alpha and Itanium. And many more if you include Windows CE
As far as I know, NT and CE are different code bases, although there might be some shared code in some layers.
Xbox, etc.
And is, I think, a PowerPC variant, so it's not as if they ported it to a completely different architecture.
But, yes, it might be possible to port NT to S/3xx or z/Architecture. The unprivileged part of the instruction set should be easy; the privileged part might be some more work - the hard part would probably be the I/O architecture, but, heck, if Linux can do it, NT can probably do it, too. ("NT" here refers to anything using that line of code bases, hence everything up to Vista, Server 2008, Windows 7.)
Hasn't Unisys been pushing Windows for mainframes for years now? Since Win2K?
link
Some of the mainframes in question are apparently built out of "Intel" processors (presumably either x86-64 or Itanium); the others appear to have proprietary Unisys chips implementing the 36-bit Univac 11xx architecture but probably also have Intel chips to run Windows. What's impressive about those is that they're apparently running the old OS for the 36-bit Univac processors on the Intel systems ("This revolutionary server features the OS 2200 operating system running on Intel(R) processors"), which probably involved at least as much work (probably via binary-to-binary translation + instruction interpretation) as the stuff the people at Mantissa have done (also probably via binary-to-binary translation + instruction interpretation, but the Mantissa people are presumably just emulating one 8-bit-byte-oriented architecture on another, not emulating a 36-bit word-oriented architecture on an 8-bit-byte-oriented architecture).
IBM was pushing Windows NT 3.51 on the mainframe back in the 1990's.
Hitachi != IBM, and DEC != IBM. The original article says:
so they were not talking about NT on S/3xx - they were talking about NT on Intel (probably Itanium, possibly x86) and Alpha, all of which I think existed at the time.
How about actually recompiling Windows into native code running on that mainframe. Now that would be impressive. Especially if it was big endian, and with unusual word sizes,
I don't think you'll get anything from IBM these days with what people would generally consider "unusual word sizes", unless they still have a few 709x's in a warehouse from the late '50's or early '60's. S/3xx was, from Day One, a 32-bit-word (originally with only 24 bits of that used in addressing, then with an option to expand to 31 bits), 8-bit-byte-addressible architecture long before the 80386 existed.
Big-endian might be more work, although I think that, for example, Connectix's/Microsoft's Virtual PC for Mac did both interpretation and binary-to-binary translation of x86 code to PPC code.
Maybe it you try to follow a NULL pointer you end up at uninitialzed memmroy. eg printf("hello %x", *NULL);
If you try to follow a null pointer on any Win32 (or presumably Win64) environment, at least the ones from Microsoft (and probably in WINE and ReactOS as well), you end up at a page mapped out of your address space, and probably get a trap/fault/signal/exception, just as you do on most versions of UN*X - at least as long as the offset from that pointer to which you're referring isn't large enough that you get past the end of the unmapped region. Most structures are probably small enough that you'll refer to the unmapped region; I guess if you have a pointer to a large-enough array and use a large-enough array index you could end up in a mapped region, although that'll probably be a read-only code region so you might still get a fault if you store into that region. (I don't know offhand how address space randomization would affect that.)
So, basically, it only has arrays in the sense the standard calls them "arrays", even though it also admits that they're actually pointers.
No. It has arrays in the sense that
It doesn't have arrays in the sense that you can assign arrays or pass them, rather than pointers to them, or pointers to non-array elements of them, to functions, or return them from functions.
So, no, they're not "actually pointers"; they're more like structures were in the old days of C, before you could assign structures, pass them as arguments, or return them from functions.
All modern C implementations use null terminated strings,
All implementations of C use or used null-terminated strings, as that's part of the language; it's not a characteristic of the implementation.
(actually, it's technically a pointer - C doesn't have real arrays)
Yes, it does have real arrays. In expressions, "array-valued" expressions are converted to "pointer-valued" expressions that point to the first element of the array (ANSI X3.159-1989, section 3.2.2.1 "Lvalues and Function Designators", 3rd paragraph).
I think Microsoft Visual C uses 0xCCCCCCCC.
No, it represents a null pointer as an all-bits-zero value, as do almost all other C implementations.
But then you have to code:
No, you don't. In the C Programming Language, if p is a pointer, then !p, p != 0, and p != NULL mean the same thing, regardless of how null pointers are represented.
Not at all. You're not testing a pointer, you're testing a boolean value. If the type casting is smart enough to check for NULL instead of 0 when converting a pointer to a bool, if(p) will work just fine.
Well, not exactly. If we're talking C, there's no notion of a "boolean" expression; the part of C that makes it work is that:
No, GP is correct. If the compiler knows the contents at address zero, and that it's not equal to CONSTANT, the optimization gives the same answer. It's a peep-hole optimization level thing.
No, the poster in question is incorrect. If a particular implementation of C happens to represent the null pointer constant in a fashion that makes it look like a pointer to location X, then the C compiler is obliged to arrange that no object live at that location, so, in this particular case, the contents at address zero are irrelevant.
Not sure if iTunes for Windows and its "Apple Update" feature is the same as the version of "Software Update" for OSX?
It's not. There may be some shard code or concepts, but "Software Update" for OS X is more like "Windows Update" for Windows, possibly with the added capability of updating Apple software that's not part of OS X (dunno if Windows Update will, for example, download and install any updates to Office that are free).
I would be willing to guess that Safari was already on your OSX MBP
Given that it's Apple's own browser and that OS X ships with a browser, yes, it is.
and perhaps the MBP 'Software updater' and/or the iTunes 'Apple Updater' did not upgrade your version of Safari automatically
No, it didn't. It offers you upgrades, but doesn't (at least by default) force them on you itself. (Sometimes when you upgrade one piece of software you have to upgrade others, e.g. you might think an iTunes upgrade won't require a reboot, but sometimes it turns out to require a QuickTime update in order to play videos again, and that will require a reboot.)
I like OSX too
Assuming you're not just trolling, you mustn't have used it recently, or mustn't have used it much, or you'd know that Safari comes with OS X as its built-in browser (similar to IE on Windows and Konqueror on OSes that come with KDE as the desktop environment) and that Software Update is an OS update feature and doesn't forcibly update software.
For example, in England if you can afford to pay for treatment you are free to do so, if you want to take out insurance to pay for treatment you are free to do so, if you want to use the National Health Service for your treatment you are free to do so.
That might not be the case in Canada. The trouble is that people criticizing "socialized medicine" sometimes pick particular characteristics of particular countries' health care systems and treat them as universal characteristics of all health care systems.
#1 ReactOS and HaikuOS can use a different file system than FAT.
So could the Linux that TomTom are using.
#2 The source code of the ReactOS and HaikuOS uses different techniques to access FAT volumes anyway.
Unless I'm missing something, the patent is about the on-disk format, not just the techniques to access the data stored in that format.
#3 Since ReactOS and HaikuOS are not as widely used as Linux, doubtful Microsoft will sue them as there is no money to be made doing so. TomTom on the other hand, earns money hand over fist and thus made themselves a target by Microsoft.
Please note this is not "suing Linux" but "Suing Tomtom" for using a Linux based solution that accesses FAT devices and stores an 8 lettered file name as a 32 filed one. Had Tomtom used Windows CE, doubtful Microsoft would have sued them.
As you note, this is "suing TomTom"; your argument appears to be that if TomTom were to use HaikuOS or ReactOS, they still would have been sued, in which case neither HaikuOS nor ReactOS would make issues like this go away.
Yes it is possible to access FAT volumes and not break any patents, and still leave them in a way that Microsoft's FAT implementation(s) can still read it. For example you can read it in the 8 character file name, as Apple's old operating systems used to do and ignore the 32 character file name.
Do the filesystems that TomTom are reading have files with long names on them? If so, then they risk infringing the patent. If not, then they could presumably just rip the VFAT stuff out of the file system code (or have somebody else do it) and get rid of their concerns for that patent.
Of course, that still leaves the patents unrelated to FAT....
Then issues like this can go away (I hope).
If you hope that Haiku's or ReactOS's FAT implementation will somehow magically not infringe the two "long filename" patents when Linux's do, you hope in vain - the patent covers how stuff is written to storage, and if you do that differently form how (V)FAT does it, you might have an interesting file system, but you wouldn't have one that can handle stuff written so that Microsoft's FAT implementation(s) can read it.
With the possible exception of the flash file system patent, the other patent issues also wouldn't be alleviated by using a different OS.
So why would Haiku or ReactOS make issues such as this go away?
Why is it safe to use MS NTFS but not FAT32??
If by "safe" you mean "safe from the Microsoft patents in question", it's because NTFS was designed to support long file names, so there was no need to use a hack of the sort described by the two long filename patents to add support for long filenames in a backwards-compatible fashion. Perhaps other Microsoft patents cover NTFS, but the ones cited in the article don't.
The patents that are not car-GPS-specific have to deal with: short filenames
Actually, from a quick read, those two patents appear to deal with stuffing long filenames into a file system originally designed only to support short filenames, in a backwards-compatible fashion. Linux's FAT implementation does do that, so that it can read and write FAT file systems with long names.
The final issue is GUI objects. How MS got a patent on this one befuddles me. Obviously, Xerox/Parc beat them to this one. Why doesn't anyone overturn this patent?
Because it's not something so simple as a patent on "GUI objects"?