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