Windows vs. Linux

[Gerhard Fiedler]

Microsoft did *NOT* write DOS

Well, they didn't write most of DOS 1.0. But it seems they did write (or at
least specify) most if not all of the rest up to DOS 6.22 or so. Which is
possibly considerable.

Part of the CP/M compatibility did include the use of / as flag-indicator
(the use of \r+\n as line ending also comes from CP/M -- in turn, CP/M
had aped these traits from some DEC minicomputer operating systems).

At the time, probably pretty good reasons for using the slash as command
line flag indicator.

Internally yes (indeed, they developed Xenix, before later selling it to
SCO), but that does not mean that "DOS was written on Xenix" because DOS
was *not* written in Microsoft, as above mentioned.

I probably should have said "everything between DOS 1.0 and DOS 6.22" was
written on Xenix, to be more precise

And, as an aside, I'm sure that MS would have sold more of their Xenix if
the market had wanted it. But the market really wanted DOS...

Gerhard

 

[Sybren Stuvel]

Gerhard Fiedler enlightened us with:

AFAIK there are few programs from Apple's \r era that still work in
the \n era systems, or am I mistaken with this?

AFAIK Mac OS X ships with an OS 9 emulator, with the purpose of
solving those issues.

I also doubt that the line terminator had any influence in Apple's
decision to change their OS. It was a mere (unintended) side effect,
not an objective. If they had chosen a line terminator, they better
had chosen \r\n (the internet email standard).

IMO it's too bad that "they" chose \r\n as the standard. Having two
bytes as the end of line marker makes sense on typewriters and
similarly operating printing equipment. Nowadays, I think having a
single byte as the EOL maker is quite a bit clearer. On the other
hand, with the use of UTF-8 encodings and the like, the
byte-to-character mapping is gone anyway, so perhaps I should just get
used to it ;-)

Unix-type systems still don't use natively the line terminator that
is used in internet email. Windows-type systems do. So when you want
to send a text file stored on a Unix-type system as email, you have
to translate the line terminations (or vice versa).

Yeah, bummer ;-)

Just as for MS there are good reasons not to "fix" the backslash now

Which are those reasons, except for backward compatability?

(what would be a good reason to change it?)

Less FAQs in this group about people putting tabs, newlines and other
characters in their filenames because they forget to escape their
backslashes?

What's so specifically bad about a "common escape character"? Any
character that has a special meaning in something can be
inconvenient when it has to be used normally. A backslash in a C
string, a dot in a regex, you probably can find examples for any
non-alphanumeric ASCII character.

True. Strings and filenames are usually tightly coupled in any program
handing files, though.

The only "problem" with the backslash is that you need to escape it
in C strings; I never had any trouble with that. BTW, are you really
sure that the backslash was a "common escape character" in the
70ies? How common was it back then? Even today, it seems to be
mostly a C idiom. (In that respect, Python is leaning on C, even
ever so slightly.)

Almost every programming language I know of uses it as the escape
character, except for perhaps VB Script and the likes. Not sure about
the different assembly languages, though.

Get over it... there are any number of definitions out there, some
better chosen than others, and most had a good set of reasons at the
time they were chosen.

Sure. I've talked more about this specific subject in this thread than
in the rest of my life ;-)

Mostly by chance, some fit better into the picture some decades
later, and some fit less nicely. Without really getting down to it,
there's no way to tell whether any of the standards was well-chosen.
Even the ones that look now as if they were... could be mere luck.

Very true. I think cooperation and uniformity can be a very good
thing. On the other hand, Microsoft want the software written for
their platform to stay on their platform. That's probably one of the
major reasons to remain incompatible with other systems.

You're of course entitled to your opinion.
Yay!

I never wanted to doubt that. But an unfounded opinion usually
tells more about the subject than the object...

I generally try to have well founded opinions And of course I want
to be open to proof that my opinion is wrong!

Sybren

 

[Sybren Stuvel]

Gerhard Fiedler enlightened us with:

Well, they didn't write most of DOS 1.0. But it seems they did write
(or at least specify) most if not all of the rest up to DOS 6.22 or
so. Which is possibly considerable.

Those are MS-DOS version numbers you're talking about. For example,
they had nothing to do with FreeDOS, which is also a DOS.

Sybren

 

[Gerhard Fiedler]

Gerhard Fiedler enlightened us with:

Those are MS-DOS version numbers you're talking about.

Of course. The issue was that I wrote that "Microsoft wrote DOS on Xenix"
and Alex objected. I was of course wrong in that totality, but then, they
still wrote everything between DOS 1.0 and 6.22 on Xenix.

For example, they had nothing to do with FreeDOS, which is also a DOS.

Yup, and a number of other DOSes like Novell DOS etc. Still all (or most?)
of these use the backslash

Gerhard

 

[Christopher Weimann]

C:\>
C:\>cd /windows/system32

C:\WINDOWS\system32>

This doesn't work the way you think it does.

C:\>cd /windows

C:\WINDOWS>cd /system32

C:\WINDOWS\system32>

C:\WINDOWS\system32>cd /windows
The system cannot find the path specified.

It IGNORES a leading / char.

--

 

[Gerhard Fiedler]

IMO it's too bad that "they" chose \r\n as the standard. Having two
bytes as the end of line marker makes sense on typewriters and
similarly operating printing equipment.

I may well be mistaken, but I think at the time they set that standard,
such equipment was still in use. So it may have been a consideration.

Nowadays, I think having a single byte as the EOL maker is quite a bit
clearer.

Rather than thinking in bytes and the like when inserting an EOL marker,
inserting really an EOL marker (that then gets translated by low level code
to the appropriate byte sequence as needed) is probably the less archaic
way to do that

On the other hand, with the use of UTF-8 encodings and the like, the
byte-to-character mapping is gone anyway, so perhaps I should just get
used to it ;-)

Yes "Bytes" is getting definitely too low level. Especially with higher
level languages like Python... there are not many byte manipulation
facilities anyway. The language is at a much higher level, and in that
sense the classic strings are a bit out of line, it seems.

Which are those reasons, except for backward compatability?

I don't know how many reasons you need besides backward compatibility, but
all the DOS (still around!) and Windows apps that would break... ?!? I
think breaking that compatibility would be more expensive than the whole
Y2k bug story. And don't be fooled... you may run a Linux system, but you'd
pay your share of that bill anyway.

Less FAQs in this group about people putting tabs, newlines and other
characters in their filenames because they forget to escape their
backslashes?

Or forget to use raw strings. (If you don't want it to be escaped, please
say so

But similar as I wrote above with the EOL thing, I think that the whole
backslash escape character story is not quite well-chosen. In a way, this a
mere C compatibility pain in the neck... (Of course there are
implementation and efficiency reasons, mainly because Python is based on C
APIs, but all that is as arbitrary as the selection of the backslash as
path separator.)

There could be other solutions (in Python, I mean). Only accept raw strings
in APIs that deal with paths? Force coders to create paths as objects, in a
portable way, maybe by removing the possibility to create paths from
strings that are more than one level in the path? Or introduce a Unicode
character that means "portable path separator"? Or whatever...

Strings and filenames are usually tightly coupled in any program
handing files, though.

Yes, and that's IMO something from way below in the implementation depths.
While file names and paths are strings, not every string is a valid and
useful file name or path. This shows that using strings for file names and
paths has tradition (coming from low level languages like C), but IMO is
not quite appropriate for a higher abstraction level.

Almost every programming language I know of uses it as the escape
character, except for perhaps VB Script and the likes. Not sure about
the different assembly languages, though.

There are so many languages... and I know so few of them...
http://en.wikipedia.org/wiki/Category:Programming_languages

Now it may be predominant (I still think it's mostly present in languages
that are in some way influenced by C), but in the 70ies?

IIRC, Pascal uses '^' for a similar purpose (not quite the same, but
similar). This form is still in ample use in documentation to mean

Sure. I've talked more about this specific subject in this thread than
in the rest of my life ;-)

There's a first for everything

I think cooperation and uniformity can be a very good thing. On the other
hand, Microsoft want the software written for their platform to stay on
their platform. That's probably one of the major reasons to remain
incompatible with other systems.

Probably. But even if I'd had a say there (and I hate switching between
separator characters just as much as the next guy, and possibly do so more
than you given that I work on a Windows system, with slashes in repository
paths and URIs), I'm not sure I'd make the jump away from the backslash as
path separator. That's just breaking too much code. You don't want to have
all these curses directed at you...

Gerhard

 

[Sybren Stuvel]

Gerhard Fiedler enlightened us with:

I don't know how many reasons you need besides backward
compatibility, but all the DOS (still around!) and Windows apps that
would break... ?!? I think breaking that compatibility would be
more expensive than the whole Y2k bug story.

Microsoft could provide an emulated environment for backward
compatability, just like Apple did. Wouldn't know what that would
cost, though.

And don't be fooled... you may run a Linux system, but you'd pay
your share of that bill anyway.

How's that?

Probably. But even if I'd had a say there [...] I'm not sure I'd
make the jump away from the backslash as path separator. That's just
breaking too much code. You don't want to have all these curses
directed at you...

I think the folks at microsoft are used to getting cursed at

Sybren

 

[Alex Martelli]

At the time, probably pretty good reasons for using the slash as command
line flag indicator.

In DEC's case, the / was an essentially random choice -- nothing
particularly stood either for or against it -- and there was no
particularly good reason for CP/M to ape it later, either (Unix is even
older than CP/M, _and_ ran on HW essentially identical to that used by
some of said DEC OS's, yet, having good designers, it "broke" both these
points of "compatibility"... yet didn't suffer in the least thereby).

The \r+\n choice is different -- it did indeed have a good reason _at
the time_ DEC chose it: for OSs without real device drivers (on machines
with no power to spare for even the most trivial processing), sending a
bunch of lines to a dumb teletype really needed the lines to be
terminated by telling the tty both to return-carriage (the \r) AND to
advance paper (the \n) -- and the former had to be first because the
carriage-return operation was mechanically slower but could occur at the
same time as the paper advance. But these issues did not apply by the
'70s, when CP/M was born and Unix got its name (from the previous name,
briefly used in the late '60s, of UNICS).

Whether there's "a good reason" to embed the consequences of these
mechanical issues in fileformats and protocols, destined no doubt to
survive for many decades to come, 40 years after said issues had become
essentially moot, is another issue... but backwards-incompatible changes
ARE always hard (and yet, the original designers of successful systems
are basically never as ambitious and visionary as to think of the effect
their choices of today will have 40 or 80 years down the road -- systems
designed with the mindset of thinking many-decades-ahead tend to fail in
their struggle against quick-and-dirty ones, as bemoaned but lucidly
analyzed in Gabriel's deservedly famous essay on "worse is better", e.g.

And, as an aside, I'm sure that MS would have sold more of their Xenix if
the market had wanted it. But the market really wanted DOS...

Yes, particularly considering the much higher HW demands of Xenix's
entry point, compared to DOS's -- not only did Xenix always require a
hard disk, but, for over 2 years, Xenix supported only Zilog Z8001 and
later Motorola 68000... it took SCO, in late 1983, to release an 8086
version, and by that time DOS was well entrenched in the marketplace,
also supporting floppy-only machines that remained a much more
affordable entry point than hard-disk ones for further years.
Basically, by the time PCs with hard disks were starting to become
widespread, MS had lost interest in marketing Xenix, which only SCO was
pushing, so it made sense in '87 for MS to sell SCO Xenix outright in
exchange for a large slice of SCO's stock (20%, if I remember right).


Alex

 

[Gerhard Fiedler]

Microsoft could provide an emulated environment for backward
compatability, just like Apple did. Wouldn't know what that would cost,
though.

Possibly. Rather than waiting for that, I think that languages that want a
degree of portability should simply provide a wrapper around this low level
system dependent stuff. There's no need to use system dependent path
separation characters in the language API.

How's that?

Pretty much every production cost increase gets in the end paid by the
consumer. With some localized changes, you may be lucky and don't buy any
products that are affected, but with such a widespread change as this would
be, it is more likely that almost everybody is affected close to average.
With that is also mostly the pressure gone to not increase -- because so
many are affected that the few who are not happily increase the prices with
the others.

The only ones likely to make a cut for a short time are a number of Windows
consultants. But those probably would be mostly either people with some
previous involvement with the product or the company, or cheap offshore
resources. Probably neither is your case...

Gerhard

 

[Alex Martelli]

Gerhard Fiedler enlightened us with:

Microsoft could provide an emulated environment for backward
compatability, just like Apple did. Wouldn't know what that would
cost, though.

I believe Microsoft could have saved many billions of dollars of
development costs, and hit the market well in time for the 2006 holiday
season, if they had designed Vista that way -- a totally new system, wih
no direct compatibility constraints, and with virtualization used to run
XP stuff. That strategy (in the Mac OS 9 -> Mac OS X migration path,
with "Classic" as the ``virtualization'' layer) is what saved Apple's
bacon when all attempts to craft compatible extensions of old Mac OS had
floundered in excessive costs and complexity. And virtualization is
obviously a prepotently emerging technology -- look at VMWare's huge
profits, at Microsoft's purchase of the makers of VirtualPC, at the rise
of Parallels, at open-source developments such as QEMU and Xen...

I think the folks at microsoft are used to getting cursed at

Particularly by their stockholders, with the stock down from a high of
almost 60 to the recent lows of below 22...


Alex

 

[Sybren Stuvel]

Gerhard Fiedler enlightened us with:

Possibly. Rather than waiting for that, I think that languages that
want a degree of portability should simply provide a wrapper around
this low level system dependent stuff. There's no need to use system
dependent path separation characters in the language API.

Could be useful to have a \p escape character that's replaced by the
system's path separator. Or have a special FileName object, that
replaces / with os.sep.

Pretty much every production cost increase gets in the end paid by
the consumer. With some localized changes, you may be lucky and
don't buy any products that are affected, but with such a widespread
change as this would be, it is more likely that almost everybody is
affected close to average.

You still don't tell me how I could be affected by a production cost
increase at a company I'm buying nothing from.

With that is also mostly the pressure gone to not increase --
because so many are affected that the few who are not happily
increase the prices with the others.

Either my English isn't as good as I thought, or that's simply
incomprehendable.

Sybren

 

[Gerhard Fiedler]

You still don't tell me how I could be affected by a production cost
increase at a company I'm buying nothing from.

You don't buy your gas as crude from Saudi Arabia oil well, do you?
Their production cost increases may affect you nevertheless.

There are very few products you buy that are only affected by costs
generated in one company. Usually that's dozens, if not hundreds of
companies in the chain. (That's not to say that all of them are relevant,
price-wise, but it's more than one that's relevant, usually.) Take your
pick, anything, and try to find out the price building chain. You may be
surprised.

Besides, you probably don't know whether it's not one of your direct
suppliers who's affected. You're sure you don't buy from anybody running a
Windows system? I'd bet against that, and I only bet when I know I win

I'm not talking about something obvious like a 10% increase. An overall
(average) 1% increase is easy to dismiss as not relevant -- but it's still
1%, if you add it up. (I'm not claiming it would be 1% though. Just an
example number.)

Either my English isn't as good as I thought, or that's simply
incomprehendable.

Possibly the latter... I'll try again

When there's a change in the cost structure of some companies, they try to
pass that on through their prices. That's just natural. If the cost
structure of a whole sector changes, that's easy, because all of them will
want to increase by the same margin, and the cost structure of the whole
sector remains the same. (See gas prices.)

If almost all of a sector are affected, this still doesn't change
(usually): the ones who are not affected often just go with the crowd and
increase nevertheless, figuring they can gain more by increased margins
than they would gain by increased market share due to lower prices. (There
are all kinds of factors that affect this; not always a lower price gets
reflected in a higher market share.)

But they (or some of them) could also decide to stay at their lower price
to gain market share. But if the production cost for 80% of a sector goes
up, it may be that the 20% who don't have that cost increase stay low, but
the average price of that sector still will go up. (Not everybody will move
to the suppliers now with lower cost.) With that, the average production
cost for companies that depend on that sector will go up. So there's an
average hike anyway, even if some or all of the ones who don't have to
increase actually don't.

Gerhard

 

[Bryan Olson]

Not from my Windows XP command prompt it doesn't. Do you have anything
strange installed on your system?

Tons of strange stuff, yes, but I just tried it on a couple
machines on display at BestBuy, and it worked as I showed it.
Maybe a recent change.

 

[Bryan Olson]

This doesn't work the way you think it does.

C:\>cd /windows

C:\WINDOWS>cd /system32

C:\WINDOWS\system32>

C:\WINDOWS\system32>cd /windows
The system cannot find the path specified.

It IGNORES a leading / char.

Ah, yes, I see.

As Gerhard Fiedler pointed out, they use '/' elsewhere on
command lines to introduce options, so it could be ambiguous as
the first character of a path name.

 

[Duncan Booth]

Tons of strange stuff, yes, but I just tried it on a couple
machines on display at BestBuy, and it worked as I showed it.
Maybe a recent change.

As other postings to this thread have shown it is simply that Windows is
taking the forward slash as introducing an option and then ignoring it
entirely if the next letter doesn't match one of the options it knows
about. So for example (/D being an option to CD):

C:\>cd /Documents and settings
The system cannot find the path specified.

C:\>cd /DDocuments and settings

C:\Documents and Settings>

 

[Sybren Stuvel]

Gerhard Fiedler enlightened us with:

You don't buy your gas as crude from Saudi Arabia oil well, do you?
Their production cost increases may affect you nevertheless.

No, but I do buy a product directly made from that oil.

Besides, you probably don't know whether it's not one of your direct
suppliers who's affected. You're sure you don't buy from anybody
running a Windows system? I'd bet against that, and I only bet when
I know I win

Good point. I don't buy much software, though. The only things I buy
are some games every now and then. The rest of what I use is Open
Source.

Thanks for the good explanation

Sybren

 

[Bryan Olson]

As other postings to this thread have shown it is simply that Windows is
taking the forward slash as introducing an option and then ignoring it
entirely if the next letter doesn't match one of the options it knows
about.

Not quite. The first slash is ambiguous and apparently ignored,
but latter slashes are taken as a path separators.

Have you determined why it didn't work on your XP box as it did
on mine and on the machines at BestBuy?

 

[Duncan Booth]

Not quite. The first slash is ambiguous and apparently ignored,
but latter slashes are taken as a path separators.

I'm not sure ambiguity enters into it. I think perhaps the bad detection of
the option happens because the CD command can ignore spaces in its
argument. Since it is ignoring spaces they don't actually require a space
after the option strings.

Any other Microsoft commands I try all complain about 'invalid switch'.

Have you determined why it didn't work on your XP box as it did
on mine and on the machines at BestBuy?

Simply that I hadn't changed to the root directory first so there was no
subdirectory named 'windows'.

 

[Bryan Olson]

I'm not sure ambiguity enters into it. I think perhaps the bad detection of
the option happens because the CD command can ignore spaces in its
argument. Since it is ignoring spaces they don't actually require a space
after the option strings.

You lost me. Spaces are significant in file names, and slashes
within the path are used as path separators, as far as I can
tell.

Try cd'ing several subdirectories deep on XP with forward
slashes. It works for me, and it could not if slashes were
ignored as you suggested.

Any other Microsoft commands I try all complain about 'invalid switch'.

The first I noticed were their build tools. Their version of
"make", called "nmake", and their visual studio tools will
accept either forward or backward slashes in paths.

Simply that I hadn't changed to the root directory first so there was no
subdirectory named 'windows'.

Ah, my example showed a particular root: "C:\". Does your system
work the same if you set the current directly as shown?

 

[andrew clarke]

James Stroud enlightened us with:

its better to use:

os.path.join('my', 'favorite', 'dir')

than

"\\".join(['my', 'favorite', 'dir'])

because the latter will bonk on linux.

Ehm... replace that with "the latter with bonk on every OS except
Microsoft Windows". Windows is the weird one in OS-land, because they
are the only one that use the most widely used escape-character (the
backslash) as path separator.

OS/2 (and eComStation) also uses the backslash as the path separator.