They wouldn't take a "bath" if they put it on the same CD as the Windows one.
It seems to me that spending 100% of the cost of supporting Linux (ie in writing the port) and then purposely desiging the distribution so that unsold boxes are returned, is some scheme by management to "prove" that supporting Linux loses money.
"MDI" means nested windows. Ie if you edit more than one document in your word processor, there is a single outer window with a menubar, and two, possibly overlapping, "inner" windows inside that. Basically it is like a mac desktop embedded into a windows/x style desktop. Everybody agrees it is a really bad design, as it combines the problems of both styles of menubar, plus wastes screen space. "MDI" was done by Microsoft so the orignal versions of Windows could avoid swapping in the unused programs to draw exposed areas, unfortunatly in typical Microsoft-brainwashing, people actually were convinced this was a good idea and, for a short while, they actually requested "MDI" as a user interface requirement!
More recently people have confused MDI with "tiled" windows. These are completely different, they replace the overlapping toolbars of programs like Photoshop with a single window where the document is a large area and the toolbars are arranged around it. I think the debate is still going on here, personally I think overlapping can work but it is being seriously botched by window systems that insist on raising windows on clicks, making it impossible to share toolbars between multiple documents, however I think I am in the minority opinion. Please don't confuse or call tiled windows "MDI".
In any case neither definition of "MDI" is really what the Macintosh does. Though I personally do not like the Mac menubar (or the many copies on X or Windows with "panels"), the arguments against MDI do not apply to these.
I agree that the scanner not working in the first place is a hardware compatability problem.
However the poster seemed to be complaining about a scanner that *was* working and suddently stopped. This *does* seem to be a problem in Linux, it has happened to me and friends of mine (for me it is sound playback which quits and does not return unless rebooting, but plays just fine when it does work, for my friend it was a PCMCIA storage card that worked perfectly until he changed something supposedly unrelated and it never worked again). These problems do indicate that something is wrong in Linux.
I think period really makes sense as it matches the syntax used by virtually all programming languages to indicate a sub-portion of a file.
The problem is that period makes so much sense that it had already been used to tack on a file extension in flat file systems. Before file extensions were used to identify type, they were used to seperate parts of files. For instance foo.pas, foo.obj and foo.com were used on RSX-11M derived operating systems to identify the Pascal source code, the compiled object code, and the executable version of the program "foo". This made period the obvious selection.
Unfortunately the need to be compatable with that forced Multics/Unix to select a different character (otherwise typical uses of foo.bar would have produced a whole lot of subdirectories, which at the time were very inefficient compared to a file).
You are right that after period, colon is the best choice. Colon was already used by RSX-11M for device selection (much like the CPM and MSDOS disk selector, and url interface selector). It does seem obvious to reuse it for directories, especially as Unix (and I think Multics) intended always to hide the devices as mount points. My best guess is that they wanted to use an unshifted character.
Slash has an obvious problem that it conflicts with how dates are written. But it is possible at the time that the idea that you would use punctuation in filenames was considered unimportant.
I think the next development would be to eliminate the reservation of *any* character in filenames, allowing them to be identified with a sequence of bytes. This will include allowing 0 and slashes in filenames, and also means that all interpretations (such as "case independence") are removed. Of course there will be some syntax and quoting done so users can type filenames, but this will be interpreted and removed by user-level code before the system is passed the filenames. By putting it at the user level, you can try different seperator characters. I think Plan9 has some of this, though they still reserve the null character.
Here's a clue: backslashes are used to quote the next character in virtually every programming language, including ones supported directly by Microsoft.
And the Win32 API supports *BOTH* forward and backward slashes. Why is that? Perhaps because they are smarter than you are and realized that it was a very well-established standard.
Now periods would be better, but when Unix was designed they were already too entrenched as the "extension seperator".
As the article states, the "blooming" effect is not HDR, it simply is blurring a white image and compositing it atop the original.
HDR really means that floating point numbers are used instead of fixed-point integers. You can easily achieve human brightness resolution with a 16-bit number, appropriately used. The EXR standard mentioned in the article is the same as IEEE 32-bit floating point, except the exponent is reduced to 5 bits, plus 1 sign bit, and a 10 bit mantissa (plus hidden 1). This allows a range of.000035 to 32768 (ie a contrast ration of over 1 billion), plus a gradual underflow area, +/-zero, +/-infinity, a full range of negative numbers, and several NaN values, all in the same 16-bit area that many images use for fixed-point.
The EXR 16-bit format is now a standard and Nvidia is putting it into hardware on their boards. It is likely that all texture maps will be in this form in the near future.
Currently the final display buffer is 8 bits, and the floating point image is converted by multiplying by a constant and truncating. The first huge improvement will be to use a lookup texture to add the gamma curve of the 8-bit displays, so that the floating point data is really brightness information, this will hugely improve the realism of these exposure and lighting setups. Currently you must use a shader program for this, but I expect it will be put in hardware soon.
More in the future are actual HDR displays. These have a contrast ratio of perhaps 80000:1, so the EXR data will still be truncated, but it well exceeds the human eye's contrast ratio (ignoring the ability of the pupil to dialate). The best technology appears to be to put a color LCD display atop a monochrome LED display.
This is not really a protection. It is certainly easy to imagine a "user friendly" email program that turns the executable bit on for you when saving an executable file. If the program is capable of figuring out what to do when you double-click the file, it can do this too.
Then again, if there was a simple "open xyz" program that could be exec'd, then implementing double-click would be trivial, and thus the programmer may avoid the complexity of turning on the executable bit. Such a program is missing from Linux/KDE/Gnome right now, this is a *serious* oversight!!!
It may be plausable to require sudo style permission to turn on the executable bit. Again I suspect this will not happen unless we get a simple "open" executable.
As I have never used outlook or whatever the culprit program is, I am confused by this "hiding extensions" problem. I see how it works but wouldn't a real jpeg file display as only "imagename" and not "imagename.jpg" and thus be somewhat discernable?
It also sounds like Windows extracts the actual icon from the.exe and displays it, which is mindboggingly stupid. They actually *know* it is an.exe file, with enough knowledge to even parse it and extract an icon! All they have to do is display a generic "exe" icon, or an obvious modification of the imbedded icon. It would seem this sort of fix could have been done years ago, why wasn't it?
What I'm proposing is that formatting is a block of data placed between characters. Sort of like old Wordstar using ^B to turn bold on/off, but using blocks of data larger than one character and with different on/off codes (probably a "push" code and a "pop" one to restore the previous format). In the word processor I worked on (in 1987) we used several control characters such as ^B to turn on bold, and ^] to "pop", and used ^K...^J as a block of formatting data. Modern designs would be much better.
This would allow many paragraphs to share the same formatting, and allow formatting to exist with no paragraph attached to it. It would also make it easy to add letters to either of two adjacent formats, depending on whether you put the insertion point before or after the format change. In thw wp I worked on it was quite easy, the arrow keys would actually stop on both sides of the formatting change, tests showed that even novices would figure this out very quickly.
I thought the MSWord paragraph styles were a big step backwards and very hard to use.
If there is no way to save formatting information without also producing a paragraph spacing, then I would say that OO is by definition broken. It does not matter whether it is compatable with Word or not, this should be possible.
It would help if OO did not copy the Word brain-damage of paragraph styles. Style information should be completely invisible things that are *between* the characters, not attached to a paragraph. I was assumming it was more intelligently designed than Word, probably my mistake.
Being in.doc formate *means* the docuement is MSWord. And there is no need for a "quirks" mode, just think about reading/writing the file as a translation, and have OO work any way it wants.
In your example where empty paragraphs are treated differently by the programs, you solve it like this:
1. On import from.doc, identify empty paragraphs and remove them.
2. On export (assumming it is necessary) replace missing paragraphs with empty ones.
3. Figure out something in MSWord that draws just like an OO empty paragraph. Perhaps a paragraph containing a single space or something. (this is admittedly the hard part, and if Word is really bad it may be impossible, but I doubt it. If you really have to do some incredible contortion it will serve as a good joke proof about how bad Word is, so I think it would be in OO's interest). On export, convert empty paragraphs to this construct.
4. On import identify the "empty paragraph replacement" and convert to an empty paragraph.
Never attribute to malice what can be explained by incompetence.
I very much doubt that even at Microsoft, anybody would purposely break an application. They just make mistakes, and they are also lazy, and often worried that they are "confusing" the user and thus pop up warnings.
This is not done with any intent to force lock-in, but the end result is the same: The program pops up scary warnings "WARNING! Some formatting may not be saved!", because the programmer was genuinely worried that they may not have back-translated everything correctly, and thinks, entirely out of benevolence, that the user should be warned. And when they do make mistakes and the program fails to load, the user remembers that scary warning, and decides to cough up the bucks to upgrade everybody. If it were not for the warning, the user would be more likely to assumme it was their fault and try again, or actually conclude that removing this table or whatever will fix the document.
I believe almost all of Microsoft's evil is actually caused by incompetence or just confusion by their programmers. In some ways the result is worse than if Microsoft actively tried to be evil.
Re:I would like to see a "More L than LGPL" licens
on
Drafting GPL3
·
· Score: 1
You can't, unless the program is obviously doing something that the library is incapable of doing and it appears impossible to add that ability without modifying the library.
But you also can't really tell if somebody is using GPL code without permission, either.
So I don't see this as any problem. You do have to rely on people being somewhat honest.
I would like to see a "More L than LGPL" license
on
Drafting GPL3
·
· Score: 4, Interesting
Yes, I know RMS does not like this idea. But there does seem to be a lot of interest in making an "LGPL" that works the way users expect. In particular this means that you can statically-link with the library and release a closed-source version of the resulting program. Yet unlike the BSD license, you are not allowed to modify the library itself without releasing your modifications.
This license serves two purposes: first it makes your library much more popular. And it should be very good for algorithims like OGG that want to be used by closed programs, by eliminating the risk of an incompatable and secret fork.
Searching around I have seen many dozens of "exceptions to the GPL" to accomplish this, indicating that there are a lot of developers that want this. A standardized version would be very useful, with a name as recognizable as "LGPL" and "BSD".
Attached is my version, which is based on wxWindows. Paragraph 2 is changed to make it clear that you must release changes to the library itself.
Comments, anybody? What are the chances of an official version of this? As far as I can tell, the desire for this is the main force behind license proliferation.
1. As a special exception, the copyright holders of this library give permission for additional uses of the text contained in this release of the library as licenced under the FLTK Library Licence, applying either version 2 of the Licence, or (at your option) any later version of the Licence as published by the copyright holders of version 2 of the Licence document.
2. The exception is that you may use, copy, link, modify and distribute, under terms of your own choice, any works based on the library (including static linking), provided that the creation of this work does not require the modification of any of the source code of the library.
3. Modifications to the source code of the library do not fall under this exception. However you may distribute the modified library under the normal terms of this license and then distribute a work using this modified library using this exception.
4. If you copy code from files distributed under the terms of the GNU General Public Licence or the GNU Library General Public Licence into a copy of this library, as this licence permits, the exception does not apply to the code that you add in this way. To avoid misleading anyone as to the status of such modified files, you must delete this exception notice from such code and/or adjust the licensing conditions notice accordingly.
5. If you write modifications of your own for this library, it is your choice whether to permit this exception to apply to your modifications. If you do not wish that, you must delete the exception notice from such code and/or adjust the licensing conditions notice accordingly.
I meant the internal binary API accepts forward slashes in filenames.
Lots of people believe otherwise. I had somebody submit an huge patch (hundreds of changes to every single source file) where they #ifdef'ed our code so that every single #include had backslashes on Windows. Pretty incredible that somebody can work so hard and yet be so ignorant.
Any idea what they are going to do about "quoting".
My recommendation is to use "\", with the trick that "\x" where x is a character that is legal and commonly used at the start of a filename, it actually expands to "/x" (not \x because it would cause problems in cases where quoting is parsed a second time).
The main reason for quoting is to avoid glob pattern characters. Fortunatly all these are illegal is DOS filenames anyway, so this would not conflict.
Punctuation marks that don't need to be quoted can be used to introduce other escape sequences. Things in Unix like "\n" can be dropped, they are rarely used. Use something like "\.123" to quote characters by code numbers (probably this should support Unicode and expand the result into UTF-8 bytes).
I would be very (pleasantly) suprised if Microsoft actaully did this. They still seem intent on making sure that there is incompatability between them and Unix.
Because foo/bar/.. does not necessarily point at foo. Imagine foo or bar are links. "." and ".." are links as well, but making them point at unexpected places is probably not a good idea.
Slashdot Mirror
They wouldn't take a "bath" if they put it on the same CD as the Windows one.
It seems to me that spending 100% of the cost of supporting Linux (ie in writing the port) and then purposely desiging the distribution so that unsold boxes are returned, is some scheme by management to "prove" that supporting Linux loses money.
"MDI" means nested windows. Ie if you edit more than one document in your word processor, there is a single outer window with a menubar, and two, possibly overlapping, "inner" windows inside that. Basically it is like a mac desktop embedded into a windows/x style desktop. Everybody agrees it is a really bad design, as it combines the problems of both styles of menubar, plus wastes screen space. "MDI" was done by Microsoft so the orignal versions of Windows could avoid swapping in the unused programs to draw exposed areas, unfortunatly in typical Microsoft-brainwashing, people actually were convinced this was a good idea and, for a short while, they actually requested "MDI" as a user interface requirement!
More recently people have confused MDI with "tiled" windows. These are completely different, they replace the overlapping toolbars of programs like Photoshop with a single window where the document is a large area and the toolbars are arranged around it. I think the debate is still going on here, personally I think overlapping can work but it is being seriously botched by window systems that insist on raising windows on clicks, making it impossible to share toolbars between multiple documents, however I think I am in the minority opinion. Please don't confuse or call tiled windows "MDI".
In any case neither definition of "MDI" is really what the Macintosh does. Though I personally do not like the Mac menubar (or the many copies on X or Windows with "panels"), the arguments against MDI do not apply to these.
I believe he was referring to the fact that the menu bar is replaced by each application, rather than each having it's own menubar.
How do most people cross a road?
First they look each way to see if any cars are coming.
How does a programmer cross a road?
First he checks to see if there is a road.
I agree that the scanner not working in the first place is a hardware compatability problem.
However the poster seemed to be complaining about a scanner that *was* working and suddently stopped. This *does* seem to be a problem in Linux, it has happened to me and friends of mine (for me it is sound playback which quits and does not return unless rebooting, but plays just fine when it does work, for my friend it was a PCMCIA storage card that worked perfectly until he changed something supposedly unrelated and it never worked again). These problems do indicate that something is wrong in Linux.
I think period really makes sense as it matches the syntax used by virtually all programming languages to indicate a sub-portion of a file.
The problem is that period makes so much sense that it had already been used to tack on a file extension in flat file systems. Before file extensions were used to identify type, they were used to seperate parts of files. For instance foo.pas, foo.obj and foo.com were used on RSX-11M derived operating systems to identify the Pascal source code, the compiled object code, and the executable version of the program "foo". This made period the obvious selection.
Unfortunately the need to be compatable with that forced Multics/Unix to select a different character (otherwise typical uses of foo.bar would have produced a whole lot of subdirectories, which at the time were very inefficient compared to a file).
You are right that after period, colon is the best choice. Colon was already used by RSX-11M for device selection (much like the CPM and MSDOS disk selector, and url interface selector). It does seem obvious to reuse it for directories, especially as Unix (and I think Multics) intended always to hide the devices as mount points. My best guess is that they wanted to use an unshifted character.
Slash has an obvious problem that it conflicts with how dates are written. But it is possible at the time that the idea that you would use punctuation in filenames was considered unimportant.
I think the next development would be to eliminate the reservation of *any* character in filenames, allowing them to be identified with a sequence of bytes. This will include allowing 0 and slashes in filenames, and also means that all interpretations (such as "case independence") are removed. Of course there will be some syntax and quoting done so users can type filenames, but this will be interpreted and removed by user-level code before the system is passed the filenames. By putting it at the user level, you can try different seperator characters. I think Plan9 has some of this, though they still reserve the null character.
Backslashes were used in Algol and many Algol-derived languages.
Here's a clue: backslashes are used to quote the next character in virtually every programming language, including ones supported directly by Microsoft.
And the Win32 API supports *BOTH* forward and backward slashes. Why is that? Perhaps because they are smarter than you are and realized that it was a very well-established standard.
Now periods would be better, but when Unix was designed they were already too entrenched as the "extension seperator".
As the article states, the "blooming" effect is not HDR, it simply is blurring a white image and compositing it atop the original.
.000035 to 32768 (ie a contrast ration of over 1 billion), plus a gradual underflow area, +/-zero, +/-infinity, a full range of negative numbers, and several NaN values, all in the same 16-bit area that many images use for fixed-point.
HDR really means that floating point numbers are used instead of fixed-point integers. You can easily achieve human brightness resolution with a 16-bit number, appropriately used. The EXR standard mentioned in the article is the same as IEEE 32-bit floating point, except the exponent is reduced to 5 bits, plus 1 sign bit, and a 10 bit mantissa (plus hidden 1). This allows a range of
The EXR 16-bit format is now a standard and Nvidia is putting it into hardware on their boards. It is likely that all texture maps will be in this form in the near future.
Currently the final display buffer is 8 bits, and the floating point image is converted by multiplying by a constant and truncating. The first huge improvement will be to use a lookup texture to add the gamma curve of the 8-bit displays, so that the floating point data is really brightness information, this will hugely improve the realism of these exposure and lighting setups. Currently you must use a shader program for this, but I expect it will be put in hardware soon.
More in the future are actual HDR displays. These have a contrast ratio of perhaps 80000:1, so the EXR data will still be truncated, but it well exceeds the human eye's contrast ratio (ignoring the ability of the pupil to dialate). The best technology appears to be to put a color LCD display atop a monochrome LED display.
This is not really a protection. It is certainly easy to imagine a "user friendly" email program that turns the executable bit on for you when saving an executable file. If the program is capable of figuring out what to do when you double-click the file, it can do this too.
Then again, if there was a simple "open xyz" program that could be exec'd, then implementing double-click would be trivial, and thus the programmer may avoid the complexity of turning on the executable bit. Such a program is missing from Linux/KDE/Gnome right now, this is a *serious* oversight!!!
It may be plausable to require sudo style permission to turn on the executable bit. Again I suspect this will not happen unless we get a simple "open" executable.
I think it's more like "here is an important update for your computer, personally signed by Bill Gates so you know it is good!"
As I have never used outlook or whatever the culprit program is, I am confused by this "hiding extensions" problem. I see how it works but wouldn't a real jpeg file display as only "imagename" and not "imagename.jpg" and thus be somewhat discernable?
.exe and displays it, which is mindboggingly stupid. They actually *know* it is an .exe file, with enough knowledge to even parse it and extract an icon! All they have to do is display a generic "exe" icon, or an obvious modification of the imbedded icon. It would seem this sort of fix could have been done years ago, why wasn't it?
It also sounds like Windows extracts the actual icon from the
What I'm proposing is that formatting is a block of data placed between characters. Sort of like old Wordstar using ^B to turn bold on/off, but using blocks of data larger than one character and with different on/off codes (probably a "push" code and a "pop" one to restore the previous format). In the word processor I worked on (in 1987) we used several control characters such as ^B to turn on bold, and ^] to "pop", and used ^K...^J as a block of formatting data. Modern designs would be much better.
This would allow many paragraphs to share the same formatting, and allow formatting to exist with no paragraph attached to it. It would also make it easy to add letters to either of two adjacent formats, depending on whether you put the insertion point before or after the format change. In thw wp I worked on it was quite easy, the arrow keys would actually stop on both sides of the formatting change, tests showed that even novices would figure this out very quickly.
I thought the MSWord paragraph styles were a big step backwards and very hard to use.
If there is no way to save formatting information without also producing a paragraph spacing, then I would say that OO is by definition broken. It does not matter whether it is compatable with Word or not, this should be possible.
It would help if OO did not copy the Word brain-damage of paragraph styles. Style information should be completely invisible things that are *between* the characters, not attached to a paragraph. I was assumming it was more intelligently designed than Word, probably my mistake.
Considering that he is also running OO on the *same* machine, claiming that the explanation is that he has viruses makes no sense, either.
I agree that his results seem to have nothing to do with any experiences I have. OO starts up much slower.
Being in .doc formate *means* the docuement is MSWord. And there is no need for a "quirks" mode, just think about reading/writing the file as a translation, and have OO work any way it wants.
.doc, identify empty paragraphs and remove them.
In your example where empty paragraphs are treated differently by the programs, you solve it like this:
1. On import from
2. On export (assumming it is necessary) replace missing paragraphs with empty ones.
3. Figure out something in MSWord that draws just like an OO empty paragraph. Perhaps a paragraph containing a single space or something. (this is admittedly the hard part, and if Word is really bad it may be impossible, but I doubt it. If you really have to do some incredible contortion it will serve as a good joke proof about how bad Word is, so I think it would be in OO's interest). On export, convert empty paragraphs to this construct.
4. On import identify the "empty paragraph replacement" and convert to an empty paragraph.
Never attribute to malice what can be explained by incompetence.
I very much doubt that even at Microsoft, anybody would purposely break an application. They just make mistakes, and they are also lazy, and often worried that they are "confusing" the user and thus pop up warnings.
This is not done with any intent to force lock-in, but the end result is the same: The program pops up scary warnings "WARNING! Some formatting may not be saved!", because the programmer was genuinely worried that they may not have back-translated everything correctly, and thinks, entirely out of benevolence, that the user should be warned. And when they do make mistakes and the program fails to load, the user remembers that scary warning, and decides to cough up the bucks to upgrade everybody. If it were not for the warning, the user would be more likely to assumme it was their fault and try again, or actually conclude that removing this table or whatever will fix the document.
I believe almost all of Microsoft's evil is actually caused by incompetence or just confusion by their programmers. In some ways the result is worse than if Microsoft actively tried to be evil.
DUH yourself. More brainwashing by current computer systems. Let me propose some alternatives to your supposedly "easy" schemes:
1.turn on, click on web browser, type URL of favorite site.
My alternative: turn on, type URL of site. (GASP! Sounds like a "hard to use" CLI!!)
2. turn on, insert disk, hit next, next, next, finished, use newly installed software.
My alternative: turn on, insert disk, use software. (if you don't want to insert disk to run software next time, software offers to install itself).
3. turn on, insert disk, hit next , next, next, finished, plug in USB hardware, use new hardware.
WTF? how about: turn on, plug in USB hardware, use new hardware?
rundll32.exe url.dll,FileProtocolHandler filename
You can't, unless the program is obviously doing something that the library is incapable of doing and it appears impossible to add that ability without modifying the library.
But you also can't really tell if somebody is using GPL code without permission, either.
So I don't see this as any problem. You do have to rely on people being somewhat honest.
Yes, I know RMS does not like this idea. But there does seem to be a lot of interest in making an "LGPL" that works the way users expect. In particular this means that you can statically-link with the library and release a closed-source version of the resulting program. Yet unlike the BSD license, you are not allowed to modify the library itself without releasing your modifications.
This license serves two purposes: first it makes your library much more popular. And it should be very good for algorithims like OGG that want to be used by closed programs, by eliminating the risk of an incompatable and secret fork.
Searching around I have seen many dozens of "exceptions to the GPL" to accomplish this, indicating that there are a lot of developers that want this. A standardized version would be very useful, with a name as recognizable as "LGPL" and "BSD".
Attached is my version, which is based on wxWindows. Paragraph 2 is changed to make it clear that you must release changes to the library itself.
Comments, anybody? What are the chances of an official version of this? As far as I can tell, the desire for this is the main force behind license proliferation.
1. As a special exception, the copyright holders of this library give
permission for additional uses of the text contained in this release of the
library as licenced under the FLTK Library Licence, applying either version 2
of the Licence, or (at your option) any later version of the Licence as
published by the copyright holders of version 2 of the Licence document.
2. The exception is that you may use, copy, link, modify and distribute, under terms of your own choice, any works based on the library (including static linking), provided that the creation of this work does not require the modification of any of the source code of the library.
3. Modifications to the source code of the library do not fall under this
exception. However you may distribute the modified library under the normal
terms of this license and then distribute a work using this modified library
using this exception.
4. If you copy code from files distributed under the terms of the GNU General
Public Licence or the GNU Library General Public Licence into a copy of this
library, as this licence permits, the exception does not apply to the code
that you add in this way. To avoid misleading anyone as to the status of such
modified files, you must delete this exception notice from such code and/or
adjust the licensing conditions notice accordingly.
5. If you write modifications of your own for this library, it is your choice
whether to permit this exception to apply to your modifications. If you do
not wish that, you must delete the exception notice from such code and/or
adjust the licensing conditions notice accordingly.
I meant the internal binary API accepts forward slashes in filenames.
Lots of people believe otherwise. I had somebody submit an huge patch (hundreds of changes to every single source file) where they #ifdef'ed our code so that every single #include had backslashes on Windows. Pretty incredible that somebody can work so hard and yet be so ignorant.
Alright! Finally!
Any idea what they are going to do about "quoting".
My recommendation is to use "\", with the trick that "\x" where x is a character that is legal and commonly used at the start of a filename, it actually expands to "/x" (not \x because it would cause problems in cases where quoting is parsed a second time).
The main reason for quoting is to avoid glob pattern characters. Fortunatly all these are illegal is DOS filenames anyway, so this would not conflict.
Punctuation marks that don't need to be quoted can be used to introduce other escape sequences. Things in Unix like "\n" can be dropped, they are rarely used. Use something like "\.123" to quote characters by code numbers (probably this should support Unicode and expand the result into UTF-8 bytes).
I would be very (pleasantly) suprised if Microsoft actaully did this. They still seem intent on making sure that there is incompatability between them and Unix.
Because foo/bar/.. does not necessarily point at foo. Imagine foo or bar are links. "." and ".." are links as well, but making them point at unexpected places is probably not a good idea.
"cd /Program*" works on most (all?) Unix shells as long as the glob pattern matches only one file.