Unix has a concept of "current working directory". Windows has an 
identical concept. But did you know that Windows keeps a working 
directory FOR EVERY DRIVE?

C:\> CD Foo
C:\Foo> D:
D:\> CD Bar
D:\Bar> E:
E:\> C:
C:\Foo> D:
D:\Bar> E:
E:\> DIR C:
--lists everything in C:\Bar--
E:\> DIR C:\
--lists everything in C:\--

How random is that?

Post a reply to this message

Am 01.06.2011 12:51, schrieb Invisible:
> Unix has a concept of "current working directory". Windows has an
> identical concept. But did you know that Windows keeps a working
> directory FOR EVERY DRIVE?

Yes.

Post a reply to this message

On 01/06/2011 12:11, clipka wrote:
> Am 01.06.2011 12:51, schrieb Invisible:
>> Unix has a concept of "current working directory". Windows has an
>> identical concept. But did you know that Windows keeps a working
>> directory FOR EVERY DRIVE?
>
> Yes.

And thus C:\ and C: are two different paths. Except that sometimes they 
point to the same place...

Post a reply to this message

Am 01.06.2011 13:18, schrieb Invisible:
> On 01/06/2011 12:11, clipka wrote:
>> Am 01.06.2011 12:51, schrieb Invisible:
>>> Unix has a concept of "current working directory". Windows has an
>>> identical concept. But did you know that Windows keeps a working
>>> directory FOR EVERY DRIVE?
>>
>> Yes.
>
> And thus C:\ and C: are two different paths. Except that sometimes they
> point to the same place...

Yes.

It's one of those relics from the time when MS-DOS started out as a CP/M 
clone with a few added features. CP/M did have the concept of drives but 
didn't have directories, so one working directory per drive would give 
you the opportunity to have programs ported from CP/M stick to drives 
only, and yet prevent them from spamming the main directories of each 
drive they'd work on.

So back then it was probably a good idea.

Post a reply to this message

On 01/06/2011 12:30, clipka wrote:

> It's one of those relics from the time when MS-DOS started out as a CP/M
> clone with a few added features. CP/M did have the concept of drives but
> didn't have directories, so one working directory per drive would give
> you the opportunity to have programs ported from CP/M stick to drives
> only, and yet prevent them from spamming the main directories of each
> drive they'd work on.
>
> So back then it was probably a good idea.

Oh... my God! o_O

Post a reply to this message

Le 2011-06-01 07:59, Invisible a écrit :
> On 01/06/2011 12:30, clipka wrote:
>
>> It's one of those relics from the time when MS-DOS started out as a CP/M
>> clone with a few added features. CP/M did have the concept of drives but
>> didn't have directories, so one working directory per drive would give
>> you the opportunity to have programs ported from CP/M stick to drives
>> only, and yet prevent them from spamming the main directories of each
>> drive they'd work on.
>>
>> So back then it was probably a good idea.
>
> Oh... my God! o_O

OSes are like cities: built on top of the ruins of older ones...

(Don't remember who said it, I think it was a PC Week columnist who was 
writing about solving a "NO ROM BASIC" error after installing Linux on 
her machine)

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>> Oh... my God! o_O
>
> OSes are like cities: built on top of the ruins of older ones...

This seems to be the main think that's broken about both Windows and 
Linux. Too many decades of backwards compatibility.

Post a reply to this message

Am 01.06.2011 15:52, schrieb Invisible:
>>> Oh... my God! o_O
>>
>> OSes are like cities: built on top of the ruins of older ones...
>
> This seems to be the main think that's broken about both Windows and
> Linux. Too many decades of backwards compatibility.

Coincidentally that's exactly what made them successful in the first 
place (as opposed to e.g. BeOS). You know, avoiding the hen-and-egg 
problem of OS vs. applications.

Hm... which makes me think: Has there ever been any attempts yet to 
implement a stand-alone JVM as an OS?

Post a reply to this message

On 6/1/2011 6:59 AM, Invisible wrote:

>> So back then it was probably a good idea.
>
> Oh... my God! o_O

That's gonna be my answer to everything: "Well, it seemed like a good 
idea at the time."


-- 
~Mike

Post a reply to this message

On Wed, 01 Jun 2011 11:51:21 +0100, Invisible wrote:

> How random is that?

Not very, it makes sense that they'd maintain the state of each drive 
letter in memory.  That's why on older DOS machines you had the LASTDRIVE 
directive in CONFIG.SYS.

Jim

Post a reply to this message

Le 2011/06/01 06:51, Invisible a écrit :
> Unix has a concept of "current working directory". Windows has an
> identical concept. But did you know that Windows keeps a working
> directory FOR EVERY DRIVE?
>
> C:\> CD Foo
> C:\Foo> D:
> D:\> CD Bar
> D:\Bar> E:
> E:\> C:
> C:\Foo> D:
> D:\Bar> E:
> E:\> DIR C:
> --lists everything in C:\Bar--
> E:\> DIR C:\
> --lists everything in C:\--
>
> How random is that?
>

Let see from way back when I was using DOS 3... Well before knowing 
anything about Windows.

Yes, I could do exactly that.


Alain

Post a reply to this message

On 01/06/2011 09:07 PM, Alain wrote:

> Let see from way back when I was using DOS 3... Well before knowing
> anything about Windows.
>
> Yes, I could do exactly that.

Well, I doubt they added it for Windows. The command prompt is pretty 
much a deprecated way of doing things. It's only supported for backwards 
compatibility. So yes, I had presumed this carried over from MS-DOS 
(although I couldn't say what version).

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> OSes are like cities: built on top of the ruins of older ones...
>>
>> This seems to be the main think that's broken about both Windows and
>> Linux. Too many decades of backwards compatibility.
>
> Coincidentally that's exactly what made them successful in the first
> place (as opposed to e.g. BeOS). You know, avoiding the hen-and-egg
> problem of OS vs. applications.

The same could be said of the ancient x86 platform, which still supports 
running obsolete versions of MS-DOS if you want to.

> Hm... which makes me think: Has there ever been any attempts yet to
> implement a stand-alone JVM as an OS?

Isn't that kind of the original *point* of Java?

Post a reply to this message

Am 02.06.2011 09:56, schrieb Invisible:
>>>> OSes are like cities: built on top of the ruins of older ones...
>>>
>>> This seems to be the main think that's broken about both Windows and
>>> Linux. Too many decades of backwards compatibility.
>>
>> Coincidentally that's exactly what made them successful in the first
>> place (as opposed to e.g. BeOS). You know, avoiding the hen-and-egg
>> problem of OS vs. applications.
>
> The same could be said of the ancient x86 platform, which still supports
> running obsolete versions of MS-DOS if you want to.

Egg-sactly.

>> Hm... which makes me think: Has there ever been any attempts yet to
>> implement a stand-alone JVM as an OS?
>
> Isn't that kind of the original *point* of Java?

Not sure; the way it is /implemented/, the JVM seems to always be an 
intermediate layer on top of some host OS. It might have gained enough 
momentum by now though that a dedicated Java OS might be successful.

Post a reply to this message

>>> Hm... which makes me think: Has there ever been any attempts yet to
>>> implement a stand-alone JVM as an OS?
>>
>> Isn't that kind of the original *point* of Java?
>
> Not sure; the way it is /implemented/, the JVM seems to always be an
> intermediate layer on top of some host OS. It might have gained enough
> momentum by now though that a dedicated Java OS might be successful.

http://en.wikipedia.org/wiki/JavaOS

(Note the "see also" section as well.)

Post a reply to this message

Am 02.06.2011 12:37, schrieb Invisible:
>>>> Hm... which makes me think: Has there ever been any attempts yet to
>>>> implement a stand-alone JVM as an OS?
>>>
>>> Isn't that kind of the original *point* of Java?
>>
>> Not sure; the way it is /implemented/, the JVM seems to always be an
>> intermediate layer on top of some host OS. It might have gained enough
>> momentum by now though that a dedicated Java OS might be successful.
>
> http://en.wikipedia.org/wiki/JavaOS
>
> (Note the "see also" section as well.)

Hm... latest news from any of those projects date from January 2009... 
so no, not enough momentum as it seems.

Post a reply to this message

>> http://en.wikipedia.org/wiki/JavaOS
>>
>> (Note the "see also" section as well.)
>
> Hm... latest news from any of those projects date from January 2009...
> so no, not enough momentum as it seems.

At some point, a couple of guys implemented an OS in Haskell.

And once they'd done it, they said "well, that was fun!", and the 
project vanished into history.

I suspect that an OS is subject to some *serious* network effects. It's 
an interesting toy project to write an OS in language XYZ, but once 
you've done it, what are you going to use it for?

(I guess this leads us back to the dead-end OSes with decades of 
backwards compatibility kludges...)

Post a reply to this message

Am 02.06.2011 14:17, schrieb Invisible:
>>> http://en.wikipedia.org/wiki/JavaOS
>>>
>>> (Note the "see also" section as well.)
>>
>> Hm... latest news from any of those projects date from January 2009...
>> so no, not enough momentum as it seems.
>
> At some point, a couple of guys implemented an OS in Haskell.

Ah - yes...

> And once they'd done it, they said "well, that was fun!", and the
> project vanished into history.
>
> I suspect that an OS is subject to some *serious* network effects. It's
> an interesting toy project to write an OS in language XYZ, but once
> you've done it, what are you going to use it for?

I think a much more important thing than "what [language] is it written 
/in/" is the question "what is it written /for/". In case of a Haskell 
OS I don't know what that would be, but in case of a Java OS it seems 
plain as hell: Run JVM bytecode. Applications are plenty for that.

> (I guess this leads us back to the dead-end OSes with decades of
> backwards compatibility kludges...)

Yep.

For instance, the virtual memory management of an OS dedicated to 
running JVM bytecode could easily provide built-in support for garbage 
collection.

Post a reply to this message

Le 2011-06-01 16:32, Orchid XP v8 a écrit :
> The command prompt is pretty much a deprecated way of doing things.

Depends on what you do.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 02/06/2011 14:30, Francois Labreque wrote:
> Le 2011-06-01 16:32, Orchid XP v8 a écrit :
>> The command prompt is pretty much a deprecated way of doing things.
>
> Depends on what you do.

As far as Microsoft is concerned, the command prompt is deprecated. You 
should at least be using PowerShell. Ideally, you should write your 
scripts in VB (or better, VB.Net), or build a custom COM module, or 
whatever. The command prompt is for backwards compatibility with MS-DOS 
(which is beyond obsolete).

Not that anybody really listens to what MS wants, mind you...

Post a reply to this message

>> I suspect that an OS is subject to some *serious* network effects. It's
>> an interesting toy project to write an OS in language XYZ, but once
>> you've done it, what are you going to use it for?
>
> I think a much more important thing than "what [language] is it written
> /in/" is the question "what is it written /for/".

Now you're talking.

> In case of a Haskell
> OS I don't know what that would be, but in case of a Java OS it seems
> plain as hell: Run JVM bytecode. Applications are plenty for that.

Has anybody written anything more substantial than Tic-Tac-Toe applets 
in Java yet?

(In the case of the Haskell OS, the design goal seems to have been 
"let's demonstrate how using Haskell leads to far fewer bugs and hence 
much greater reliability". Once they proved that this was so, they got 
bored and did something else. Personally, the idea of a more reliable OS 
is something that sounds pretty appealing to me!)

> For instance, the virtual memory management of an OS dedicated to
> running JVM bytecode could easily provide built-in support for garbage
> collection.

Well now, let's examine that for a moment.

Every OS I know is based around a series of assumptions. In particular, 
that a "program" is just a monolithic block of machine code, and that 
the only "services" that it needs from the OS is resource allocation, 
protection, and control over the hardware.

Given how many kinds of programming languages these days use garbage 
collection strategies, an OS with that wired into the kernel sounds like 
quite a promising idea...

...until you realise that changing the design of the GC is likely to 
break all your applications. Unless they're written in a sufficiently 
high-level language that they can't "see" this level of detail.

So yes, the Java VM, or something like it, seems like a rather promising 
idea...

That makes you start to think what /other/ kinds of services you might 
want the OS to provide. For example, this whole "a command is a file 
name, and its arguments are strings passed uninterpretted to the 
program" thing. Surely we can do better.

Post a reply to this message

Am 02.06.2011 16:38, schrieb Invisible:
>>> I suspect that an OS is subject to some *serious* network effects. It's
>>> an interesting toy project to write an OS in language XYZ, but once
>>> you've done it, what are you going to use it for?
>>
>> I think a much more important thing than "what [language] is it written
>> /in/" is the question "what is it written /for/".
>
> Now you're talking.
>
>> In case of a Haskell
>> OS I don't know what that would be, but in case of a Java OS it seems
>> plain as hell: Run JVM bytecode. Applications are plenty for that.
>
> Has anybody written anything more substantial than Tic-Tac-Toe applets
> in Java yet?

Java Enterprise applications, anyone?
OpenOffice?
Eclipse?
Minecraft?

Just four examples of non-trivial software from four different domains 
(business software, office software, software development, and gaming) 
that pop to my mind instantaneously.


> That makes you start to think what /other/ kinds of services you might
> want the OS to provide. For example, this whole "a command is a file
> name, and its arguments are strings passed uninterpretted to the
> program" thing. Surely we can do better.

Like, say, passing messages to the program after it has been started?

I don't see much of a point in an elaborate interface to feed parameters 
at the very moment of startup; after all, the program can't evaluate 
them anyway until it has at least "started up a bit", so pushing the 
same information into a message queue seems to be pretty equivalent to me.

Unless, of course, we'd go all the way of allowing programms to pass 
around full-fledged Java objects to children, parents, or any other 
program they happen to have a handle object for.

Of course, to go for cloud computing, passing around objects should be 
transparent, via marshalling and stuff - and in the end we'd probably 
end up re-inventing the Java Enterprise architecture...

Post a reply to this message

>> Has anybody written anything more substantial than Tic-Tac-Toe applets
>> in Java yet?
>
> Java Enterprise applications, anyone?
> OpenOffice?
> Eclipse?
> Minecraft?
>
> Just four examples of non-trivial software from four different domains
> (business software, office software, software development, and gaming)
> that pop to my mind instantaneously.

As best as I can tell, OpenOffice is not "written in Java", it's written 
in C++ and it merely /uses/ Java for a few auxiliary functions.

Eclipse, on the other hand, appears to actually be Java. (I can't say 
I've ever tried to use it.)

And I don't give a stuff what the hell Minecraft is written in. :-P

>> That makes you start to think what /other/ kinds of services you might
>> want the OS to provide. For example, this whole "a command is a file
>> name, and its arguments are strings passed uninterpretted to the
>> program" thing. Surely we can do better.
>
> Like, say, passing messages to the program after it has been started?
>
> I don't see much of a point in an elaborate interface to feed parameters
> at the very moment of startup; after all, the program can't evaluate
> them anyway until it has at least "started up a bit", so pushing the
> same information into a message queue seems to be pretty equivalent to me.

If the command shell knows stuff about the syntax that commands expect, 
it can do helpful stuff for you before the command even runs. (E.g., if 
the third parameter is a number, don't do filename auto-complete on it.) 
There are lots of commands that have "sub-commands"; the shell could 
list them for you. And so on.

> Unless, of course, we'd go all the way of allowing programms to pass
> around full-fledged Java objects to children, parents, or any other
> program they happen to have a handle object for.

Well, yes. When your OS is written in the same language as your 
development language, you can do random stuff like that.

Exhibit A: Smalltalk.

Post a reply to this message

On Thu, 02 Jun 2011 15:31:18 +0100, Invisible wrote:

> On 02/06/2011 14:30, Francois Labreque wrote:
>> Le 2011-06-01 16:32, Orchid XP v8 a écrit :
>>> The command prompt is pretty much a deprecated way of doing things.
>>
>> Depends on what you do.
> 
> As far as Microsoft is concerned, the command prompt is deprecated. You
> should at least be using PowerShell. 

Those two statements contradict each other.  PowerShell is a command 
prompt, is it not?

> Ideally, you should write your
> scripts in VB (or better, VB.Net), or build a custom COM module, or
> whatever. The command prompt is for backwards compatibility with MS-DOS
> (which is beyond obsolete).
> 
> Not that anybody really listens to what MS wants, mind you...

Thank goodness for that. :)

Jim

Post a reply to this message

>> As far as Microsoft is concerned, the command prompt is deprecated. You
>> should at least be using PowerShell.
>
> Those two statements contradict each other.  PowerShell is a command
> prompt, is it not?

PowerShell is a replacement for the old MS-DOS command prompt emulator.

>> Not that anybody really listens to what MS wants, mind you...
>
> Thank goodness for that. :)

Well... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Thu, 02 Jun 2011 21:39:19 +0100, Orchid XP v8 wrote:

>>> As far as Microsoft is concerned, the command prompt is deprecated.
>>> You should at least be using PowerShell.
>>
>> Those two statements contradict each other.  PowerShell is a command
>> prompt, is it not?
> 
> PowerShell is a replacement for the old MS-DOS command prompt emulator.

So that would be "yes" then. :)

>>> Not that anybody really listens to what MS wants, mind you...
>>
>> Thank goodness for that. :)
> 
> Well... ;-)

MS is in it for the money and for their self-interest.  That's what 
drives the organization.  (That's certainly true of most for-profit 
businesses)

Jim

Post a reply to this message

Am 02.06.2011 22:37, schrieb Jim Henderson:
> On Thu, 02 Jun 2011 15:31:18 +0100, Invisible wrote:
>
>> On 02/06/2011 14:30, Francois Labreque wrote:
>>> Le 2011-06-01 16:32, Orchid XP v8 a écrit :
>>>> The command prompt is pretty much a deprecated way of doing things.
>>>
>>> Depends on what you do.
>>
>> As far as Microsoft is concerned, the command prompt is deprecated. You
>> should at least be using PowerShell.
>
> Those two statements contradict each other.  PowerShell is a command
> prompt, is it not?

Note the tiny difference between "/a/ command prompt" and "/the/ command 
prompt" :-P

And no, neither is a "command prompt" in the literal sense; I guess a 
proper term might be "command shell" ;-)

Post a reply to this message

On Fri, 03 Jun 2011 00:46:12 +0200, clipka wrote:

> Am 02.06.2011 22:37, schrieb Jim Henderson:
>> On Thu, 02 Jun 2011 15:31:18 +0100, Invisible wrote:
>>
>>> On 02/06/2011 14:30, Francois Labreque wrote:
>>>> Le 2011-06-01 16:32, Orchid XP v8 a écrit :
>>>>> The command prompt is pretty much a deprecated way of doing things.
>>>>
>>>> Depends on what you do.
>>>
>>> As far as Microsoft is concerned, the command prompt is deprecated.
>>> You should at least be using PowerShell.
>>
>> Those two statements contradict each other.  PowerShell is a command
>> prompt, is it not?
> 
> Note the tiny difference between "/a/ command prompt" and "/the/ command
> prompt" :-P
> 
> And no, neither is a "command prompt" in the literal sense; I guess a
> proper term might be "command shell" ;-)

Details, details. ;)

Jim

Post a reply to this message

>>>> As far as Microsoft is concerned, the command prompt is deprecated.
>>>> You should at least be using PowerShell.
>>>
>>> Those two statements contradict each other.  PowerShell is a command
>>> prompt, is it not?
>>
>> PowerShell is a replacement for the old MS-DOS command prompt emulator.
>
> So that would be "yes" then. :)

The old MS-DOS emulator is deprecated. CLI interfaces in general are 
not, no.

> MS is in it for the money and for their self-interest.  That's what
> drives the organization.  (That's certainly true of most for-profit
> businesses)

Corporations vary by their level of indifference towards their 
customers' interests.

Post a reply to this message

Am 03.06.2011 09:45, schrieb Invisible:

>> MS is in it for the money and for their self-interest. That's what
>> drives the organization. (That's certainly true of most for-profit
>> businesses)
>
> Corporations vary by their level of indifference towards their
> customers' interests.

No. Corporations vary by how much they expect to benefit/lose from 
satisfied/unhappy customers.

Post a reply to this message

>> Corporations vary by their level of indifference towards their
>> customers' interests.
>
> No. Corporations vary by how much they expect to benefit/lose from
> satisfied/unhappy customers.

There have been corporations who have a mentality that making their 
customers happy is literally the most important thing in the world. More 
important than making a profit, even. Now, whether anybody who thinks 
like this stays in business for more than five minutes is somewhat open 
to debate. But clearly some businesses do operate like this.

At the other end of the spectrum, we find companies who would quite 
happily provoke global thermonuclear warfare if they thought it would be 
profitable.

Post a reply to this message

Le 2011-06-03 05:08, Invisible a écrit :
>
> At the other end of the spectrum, we find companies who would quite
> happily provoke global thermonuclear warfare if they thought it would be
> profitable.

"Our earning forecast for the next quarter is for a double-digit growth, 
however, the outlook for the longer term is a little less optimistic. We 
will need to study the market and adapt our strategy to focus on growth 
sectors."

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 03/06/2011 01:43 PM, Francois Labreque wrote:
> Le 2011-06-03 05:08, Invisible a écrit :
>>
>> At the other end of the spectrum, we find companies who would quite
>> happily provoke global thermonuclear warfare if they thought it would be
>> profitable.
>
> "Our earning forecast for the next quarter is for a double-digit growth,
> however, the outlook for the longer term is a little less optimistic. We
> will need to study the market and adapt our strategy to focus on growth
> sectors."

lolrus

Yeah, well, big business is somewhat noted for short-sighted decisions...

Post a reply to this message

Am 03.06.2011 11:08, schrieb Invisible:
>>> Corporations vary by their level of indifference towards their
>>> customers' interests.
>>
>> No. Corporations vary by how much they expect to benefit/lose from
>> satisfied/unhappy customers.
>
> There have been corporations who have a mentality that making their
> customers happy is literally the most important thing in the world. More
> important than making a profit, even. Now, whether anybody who thinks
> like this stays in business for more than five minutes is somewhat open
> to debate. But clearly some businesses do operate like this.

But why do they do it? Because they think it benefits /them/ to have a 
corporate image of acting morally.

Small companies led by their owners in person (or even large companies 
led by their owners in person, though those are quite rare) are a 
different story. But corporations led by a board & traded on stock 
exchange markets? Show me a single one that acts morally for the pure 
sake of it.

Post a reply to this message

Le 03/06/2011 14:43, Francois Labreque a écrit :
> Le 2011-06-03 05:08, Invisible a écrit :
>>
>> At the other end of the spectrum, we find companies who would quite
>> happily provoke global thermonuclear warfare if they thought it would be
>> profitable.
> 
> "Our earning forecast for the next quarter is for a double-digit growth,
> however, the outlook for the longer term is a little less optimistic. We
> will need to study the market and adapt our strategy to focus on growth
> sectors."

It's the new nomadic way of life: hunt, rape, burn and move further.

The opposite way (as in Cain vs Abel) could sound:

"Our installed based is stable and we foresee no interesting events for
the next quarter. We are studying a long term evolution to provide more
facilities and ease the life of everyone."

Post a reply to this message

On Fri, 03 Jun 2011 08:45:33 +0100, Invisible wrote:

>>>> Those two statements contradict each other.  PowerShell is a command
>>>> prompt, is it not?
>>>
>>> PowerShell is a replacement for the old MS-DOS command prompt
>>> emulator.
>>
>> So that would be "yes" then. :)
> 
> The old MS-DOS emulator is deprecated. CLI interfaces in general are
> not, no.

But that's what you seemed to be saying.

>> MS is in it for the money and for their self-interest.  That's what
>> drives the organization.  (That's certainly true of most for-profit
>> businesses)
> 
> Corporations vary by their level of indifference towards their
> customers' interests.

Some corporations are happy to *tell* the customer what the customer's 
interest is.

Jim

Post a reply to this message

On 6/1/2011 3:51, Invisible wrote:
> How random is that?

It's not at all random. It's also the reason you can unmount a drive where 
your cwd is set in Windows and not in UNIX.

Remember that DOS 1 was based on CP/M, and thus didn't have directories at 
all. When directories were added, the idea was that for each drive letter, 
you set the directory you wanted, then started up the program which would 
not refer to directories at all, but only to DOS 1 a la CP/M drive letters.

How come every time you come across legacy support, you say it's a kludge or 
a wtf or a random? :-)

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/2/2011 0:56, Invisible wrote:
> Isn't that kind of the original *point* of Java?

Sort of. The idea was to insulate you from whatever was underneath, so you 
could write UI applications and such (the sorts of things you'd see on a 
smart TV or DVR or whatever) without worrying about porting them to other 
machines.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/2/2011 7:38, Invisible wrote:
> Every OS I know is based around a series of assumptions. In particular, that
> a "program" is just a monolithic block of machine code, and that the only
> "services" that it needs from the OS is resource allocation, protection, and
> control over the hardware.

You should read about Singularity, wherein this is exactly the problem being 
addressed. "Why do all the OSes do this? Because that's what an OS was 
needed for in the 1970's, the early days of timeshare. Let's see what an OS 
needs to do today...."

> ...until you realise that changing the design of the GC is likely to break
> all your applications. Unless they're written in a sufficiently high-level
> language that they can't "see" this level of detail.

Yep. That's exactly what Singularity does. Except the "high-level language" 
is basically MSIL, and the GC engine is compiled into each program, so 
different programs can use different GC engines.

> That makes you start to think what /other/ kinds of services you might want
> the OS to provide. For example, this whole "a command is a file name, and
> its arguments are strings passed uninterpretted to the program" thing.
> Surely we can do better.

If you really want to see, look at some of the new OS research. Read the 
Singularity design documents, for example. There's some really cool stuff in 
there when you get an OS that can rely on your programs actually declaring 
in their manifest what resources they need and the OS can rely on the 
programs actually obeying the semantics of the OS. (E.g., you get stuff like 
bits of the kernel being compiled into the executable code for efficiency, 
stuff like page faults being handled in user space, etc.)

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/2/2011 7:38, Invisible wrote:
> That makes you start to think what /other/ kinds of services you might want
> the OS to provide.

Or, alternately, look at Eros or Ameoba. Both are pretty easy to understand, 
both are very very unlike the usual timeshare OSes.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/1/2011 13:32, Orchid XP v8 wrote:
> I had presumed this carried over from MS-DOS
> (although I couldn't say what version).

Version 2.0 introduced directories, as well as the path-like calls (i.e., 
where you pass the file name as a UNIXy string rather than a FCB).

Version 3.22 was the first that actually looked at the control information 
in the boot sector to decide how many sectors were on the floppy and such.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/2/2011 13:37, Jim Henderson wrote:
> Those two statements contradict each other.  PowerShell is a command
> prompt, is it not?

It's a command line interpreter. You'll confuse the crap out of everyone if 
you call it a "command prompt", since the old command interpreter is called 
"command".

It would be like calling a .pov file a "batch file" of SDL commands.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Am 06.06.2011 18:17, schrieb Darren New:

> If you really want to see, look at some of the new OS research. Read the
> Singularity design documents, for example. There's some really cool
> stuff in there when you get an OS that can rely on your programs
> actually declaring in their manifest what resources they need and the OS
> can rely on the programs actually obeying the semantics of the OS.
> (E.g., you get stuff like bits of the kernel being compiled into the
> executable code for efficiency, stuff like page faults being handled in
> user space, etc.)

/Relying/ on the programs /obeying/ anything particular?

 From what you write, it sounds like the inventors of that OS have never 
heard the term "malware" in their whole life.

Post a reply to this message

On 6/6/2011 10:32, clipka wrote:
> /Relying/ on the programs /obeying/ anything particular?

Yes, because the executable MSIL code is checked for correctness by code 
that has, in turn, been proven to be correct. Just as one example. Or 
because the kernel code is mathematically proven to be correct.

Of course, if you corrupt the hardware like in the Sony example, that's 
something rather beyond what I'd call "malware".

>  From what you write, it sounds like the inventors of that OS have never
> heard the term "malware" in their whole life.

It's Microsoft. I'm pretty sure they've heard of malware. Indeed, the whole 
point of designing it like they did is, for one thing, to keep malware from 
running. I'm pretty sure, for example, that there's no formal mathematical 
proof that keeps Linux, for example, from letting a process access memory 
belonging to another process. Nor is there a mechanism in place in most 
operating systems to restrict file access to only those files a program 
declares at compile time that it will access, or to keep a device driver 
from accessing arbitrary other device addresses, or to limit authorization 
based on which program did the authentication. Indeed, in the current 
incarnation, it's impossible to modify the collection of executable code 
without rebooting the machine; installing a program is the only way to 
modify what can be executed, and that in turn requires a reboot. (Altho I'm 
pretty sure that's merely a limitation, not a design intention.)

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 06/06/2011 05:10 PM, Darren New wrote:
> On 6/1/2011 3:51, Invisible wrote:
>> How random is that?
>
> It's not at all random. It's also the reason you can unmount a drive
> where your cwd is set in Windows and not in UNIX.

Actually, last time I tried it, you can't do this in Windows either.

> How come every time you come across legacy support, you say it's a
> kludge or a wtf or a random? :-)

What was a good idea 40 years ago is not necessarily a good idea today.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 6/6/2011 11:05, Darren New wrote:
> I'm pretty sure, for example, that there's no formal mathematical
> proof that keeps Linux, for example, from letting a process access memory
> belonging to another process.

For that matter, there's very few systems out there that require all your 
code to be digitally signed and which checks it every time you fire it up, 
other than game consoles and phones for copy-protection purposes.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Am 06.06.2011 20:14, schrieb Darren New:

> For that matter, there's very few systems out there that require all
> your code to be digitally signed and which checks it every time you fire
> it up, other than game consoles and phones for copy-protection purposes.

... and still, even /those/ seem to keep dropping their pants if 
addressed in the right manner. And you'd think, if anyone is willing to 
invest real money into such systems, it would be the makers of such 
systems (apart from military or secret agencies of course).

Seems like the problem is not /that/ easily solved...

Post a reply to this message

On 6/6/2011 11:10, Orchid XP v8 wrote:
> Actually, last time I tried it, you can't do this in Windows either.

Not only can you dismount it, when you remount it, you have the same cwd.

Since every drive has a cwd, it would be impossible to dismount any drive if 
you couldn't dismount one where you had a cwd set.

>> How come every time you come across legacy support, you say it's a
>> kludge or a wtf or a random? :-)
>
> What was a good idea 40 years ago is not necessarily a good idea today.

That doesn't make it a kludge or a wtf or a random. It makes it an idea 
whose time has passed.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 6/6/2011 12:51, clipka wrote:
> ... and still, even /those/ seem to keep dropping their pants if addressed
> in the right manner.

Usually through the use of a hardware hack, tho.

The Sony hack required him to actually wire up the motherboard with  switch 
shorting out traces. The XBox hack was, IIRC, not so much a flaw in the 
security of the system, but a broken game that let you run code from a saved 
game (via buffer overflow or some such).

That's exactly why you need to do something like formal logical checks that 
your code does the right thing at the lowest levels, then make everyone 
conform to that.

When you're talking security against malware rather than copy protection, 
it's a lot easier to get right, in some ways, because you don't *ever* want 
the malware to run.  Nobody is going to be sticking debuggers on the chip or 
shorting out motherboard traces in order to get malware running on their own 
machine.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Am 06.06.2011 22:15, schrieb Darren New:
> On 6/6/2011 12:51, clipka wrote:
>> ... and still, even /those/ seem to keep dropping their pants if
>> addressed
>> in the right manner.
>
> Usually through the use of a hardware hack, tho.
>
> The Sony hack required him to actually wire up the motherboard with
> switch shorting out traces. The XBox hack was, IIRC, not so much a flaw
> in the security of the system, but a broken game that let you run code
> from a saved game (via buffer overflow or some such).
>
> That's exactly why you need to do something like formal logical checks
> that your code does the right thing at the lowest levels, then make
> everyone conform to that.

Ah yes - a formal proof... pretty useful if your intention is to make 
sure a security-critical system never fails due to unforeseen errors.

As for making sure that a system is secure against /malicious intent/, I 
believe it's pretty useless.

Just have a look at smart cards: For a given smart card design, you may 
formally prove that there is no input sequence that makes the card 
disclose even a single bit of its secret key...

... on its /official/ interface, i.e. the I2C bus data lines. But such a 
formal analysis typically forgets a few other channels on which the 
device is leaking information. For instance, an analysis may forget 
about the timing of the data output, which might give hints about what's 
going on inside. Or the power the chip consumes at any given time.

Say you will - I think a formal analysis can never foresee /all/ 
possible attack vectors a system might exhibit.

Post a reply to this message