Windows vs. Linux

[Gerhard Fiedler]

Re: Windows vs. Linux

On 2006-08-02 13:24:10, Dennis Lee Bieber wrote:

Change Directory may work... but
>
C:\Documents and Settings\Dennis Lee Bieber>cd c:\
>
C:\>cd /windows/system32
>
C:\WINDOWS\SYST EM32>cd c:\
>
C:\>dir /windows/system32
Parameter format not correct - "windows".

Since '/' is used as standard command line parameter separator, any command
that uses standard Windows command line parameters can't accept a path with
'/' as argument; it wouldn't know how to differentiate between a path
element and an argument. Try

C:\>dir "/windows/system32"


That was one of the original reasons for using backslashes as path
separator: the existing code base that used the slash as command line
argument separator.

Gerhard

[Gerhard Fiedler]

Re: Windows vs. Linux

On 2006-08-02 12:41:44, Alex Martelli wrote:

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

[Gerhard Fiedler]

Re: Windows vs. Linux

On 2006-08-02 17:38:54, Sybren Stuvel wrote:

Gerhard Fiedler enlightened us with:

>>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.

>
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]

Re: Windows vs. Linux

On 08/02/2006-08:06AM, bryanjugglercry ptographer@yaho o.com wrote:

>

From a WinXP command prompt:

>
C:\>
C:\>cd /windows/system32
>
C:\WINDOWS\syst em32>
>
>

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

C:\>cd /windows

C:\WINDOWS>cd /system32

C:\WINDOWS\syst em32>

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

It IGNORES a leading / char.

--
------------------------------------------------------------
Christopher Weimann

http://www.k12usa.com

K12USA.com Cool Tools for Schools!
------------------------------------------------------------

[Gerhard Fiedler]

Re: Windows vs. Linux

On 2006-08-02 17:36:06, Sybren Stuvel wrote:

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.

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

>
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
"Ctrl-<char>"; probably much more common than the backslash notation.

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

[Alex Martelli]

Re: Windows vs. Linux

Gerhard Fiedler <gelists@gmail. comwrote:
...

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.

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.
at <http://www.jwz.org/doc/worse-is-better.html>).

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]

Re: Windows vs. Linux

On 2006-08-02 21:09:43, Sybren Stuvel wrote:

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.

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

>
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]

Re: Windows vs. Linux

Sybren Stuvel <sybrenUSE@YOUR thirdtower.com. imaginationwrot e:

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.

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 ``virtualizatio n'' 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

[Bryan Olson]

Re: Windows vs. Linux

Duncan Booth wrote:

bryanjugglercry ptographer@yaho o.com wrote:
>

>From a WinXP command prompt:

>>
> C:\>
> C:\>cd /windows/system32
>>
> C:\WINDOWS\syst em32>
>>
>>

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

[Bryan Olson]

Re: Windows vs. Linux

Christopher Weimann wrote:

On 08/02/2006-08:06AM, bryanjugglercry ptographer@yaho o.com wrote:

>From a WinXP command prompt:
>>
> C:\>
> C:\>cd /windows/system32
>>
> C:\WINDOWS\syst em32>
>>
>>

>
>
This doesn't work the way you think it does.
>
C:\>cd /windows
>
C:\WINDOWS>cd /system32
>
C:\WINDOWS\syst em32>
>
C:\WINDOWS\syst em32>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.


--
--Bryan

[Gerhard Fiedler]

Re: Windows vs. Linux

On 2006-08-03 04:53:11, Sybren Stuvel wrote:

>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.

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.)

>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
incomprehendabl e.

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

[Duncan Booth]

Re: Windows vs. Linux

Bryan Olson wrote:

Duncan Booth wrote:

>bryanjugglercry ptographer@yaho o.com wrote:
>>

>>From a WinXP command prompt:
>>>
>> C:\>
>> C:\>cd /windows/system32
>>>
>> C:\WINDOWS\syst em32>
>>>
>>>

>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.
>

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>

[Bryan Olson]

Re: Windows vs. Linux

Duncan Booth wrote:

Bryan Olson wrote:
>

>Duncan Booth wrote:

>>bryanjugglercry ptographer@yaho o.com wrote:
>>>
>>>From a WinXP command prompt:
>>>>
>>> C:\>
>>> C:\>cd /windows/system32
>>>>
>>> C:\WINDOWS\syst em32>
>>>>
>>>>
>>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.
>>

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?


--
--Bryan

[Duncan Booth]

Re: Windows vs. Linux

Bryan Olson wrote:

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]

Re: Windows vs. Linux

Duncan Booth wrote:

Bryan Olson wrote:
>

>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.

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.

>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'.

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


--
--Bryan