Two big problems: Shells and Disk layout!

[Andrew Wilcox [maintainer]]

When I started this project four years ago, my *original* idea was to
have two shells: one like DOS, and one like UNIX. Now I can see that
this will be a problem. Especially with my new command table idea
(more about this later on the 'blog). If we want AWOS to live up to
its name, the Universal Operating System, we would have to implement at
least a DOS-like shell and support for csh. Also, which shall we start
developing first? This is debugging-related too, as the shell we put
in first is also what we debug first.

This brings me to my other prediciment. Windows apps expect drives,
like "A:" for floppy, "C:" for /dev/hda1, etc.. Linux apps expect,
well, at most the different drives to live at /mnt or /media. How are
we to handle this? I thought maybe have two partitions, a Windows
partition (e.g. C:\AWOS, C:\Programs), and a Linux parition (/sys,
/usr/bin). But is that idea feasible in real life? I understand that
the user could install one and add one later, but partitioning can be a
pain when there's a bunch of data, and it's also potentially risky.
Although mandating two partitions wouldn't be a good idea either.

I know we're still working on Build 9, but it's never too early to
think about these things. Plus, now that we're going to have support
for IDE devices, and the file systems that go with them, we will *need*
a shell to cd and ls in. :)

Best regards,

Andrew

[d4rk...@gmail.com]

Andrew Wilcox [maintainer] wrote:
> When I started this project four years ago, my *original* idea was to
> have two shells: one like DOS, and one like UNIX. Now I can see that
> this will be a problem. Especially with my new command table idea
> (more about this later on the 'blog). If we want AWOS to live up to
> its name, the Universal Operating System, we would have to implement at
> least a DOS-like shell and support for csh. Also, which shall we start
> developing first? This is debugging-related too, as the shell we put
> in first is also what we debug first.

Honestly I don't see the interest of developing a DOS-like shell, this
is totally obsolete and unusable (no completion, no command
combination, no nothing) and on the other hand unix-like shells are not
perfect either, if you really want to create a shell why not make a new
one with a standard among the commands and advanced command combination
(that would go further than the pipes). The new shell for windows (I
forgot the name) has some good ideas. I'm not sure of your goal but
making an OS both compatible with windows and unix worlds doesn't mean
you must implement all their failures :)
Despite this is a 30 years old concept, the CLI and shells can still be
improved.

>
> This brings me to my other prediciment. Windows apps expect drives,
> like "A:" for floppy, "C:" for /dev/hda1, etc.. Linux apps expect,
> well, at most the different drives to live at /mnt or /media. How are
> we to handle this? I thought maybe have two partitions, a Windows
> partition (e.g. C:\AWOS, C:\Programs), and a Linux parition (/sys,
> /usr/bin). But is that idea feasible in real life? I understand that
> the user could install one and add one later, but partitioning can be a
> pain when there's a bunch of data, and it's also potentially risky.
> Although mandating two partitions wouldn't be a good idea either.

What about using a single implementation (or a new one) between the two
existing and implementing an abstraction layer for the applications
using the other one? I don't know if it is possible, but I feel that
using the both at the same time will be an horrible mess. There must be
a convergence somewhere. Technically both windows and linux apps use
software interrupts for the system calls, so it should be possible to
built a layer at this level.

>
> I know we're still working on Build 9, but it's never too early to
> think about these things. Plus, now that we're going to have support
> for IDE devices, and the file systems that go with them, we will *need*
> a shell to cd and ls in. :)

Indeed :)
Is the IDE driver ready? I did not check the release for a while.

Good job anyway.

--
d4rk

[Andrew Wilcox [maintainer]]

d4rk...@gmail.com wrote:
> Honestly I don't see the interest of developing a DOS-like shell, this
> is totally obsolete and unusable (no completion, no command
> combination, no nothing)

Well that's true, but the point is that some people *do* still use
Windows NT-based systems (2000 and even XP) that use MS-DOS as the
beginnings of it's command prompt. Some people even still use Windows
9x which is actually running on top of MS-DOS.

At a compatibility view, we would really have to make a DOS-like shell.
Command completion is a good idea, and that would be almost too easy
to do, just grab what's been typed in to the buffer, then cross-ref
with the command line table, CWD and all folders in $PATH. I don't see
a problem with making DOS better :)

> and on the other hand unix-like shells are not
> perfect either, if you really want to create a shell why not make a new
> one with a standard among the commands and advanced command combination
> (that would go further than the pipes).

Well, that's a good idea, ash (Andrew SHell) could do that, but I think
we should probably get the DOS- and/or UNIX-type shells working first.

> The new shell for windows (I
> forgot the name) has some good ideas.

I'm assuming you mean for Vista? I haven't heard anything about it's
shell.

> I'm not sure of your goal but
> making an OS both compatible with windows and unix worlds doesn't mean
> you must implement all their failures :)

Well that's true, but we must not forget the user that will be *using*
it. He's going to expect either COMMAND.COM or csh to come up.

> Despite this is a 30 years old concept, the CLI and shells can still be
> improved.

Yeah, and my table idea is a good start. (I'll post to my blog soon.)

> What about using a single implementation (or a new one) between the two
> existing and implementing an abstraction layer for the applications
> using the other one? I don't know if it is possible, but I feel that
> using the both at the same time will be an horrible mess. There must be
> a convergence somewhere. Technically both windows and linux apps use
> software interrupts for the system calls, so it should be possible to
> built a layer at this level.

Well, the thing is, if someone is a Windows-only user, and makes a FAT
partition, then runs a Linux app that needs to check permissions or
something, well, we have a mess. The only options are as you said
writing an abstraction layer; or, we could mandate ext3 or NTFS (NTFS
has permissions).

> Indeed :)
> Is the IDE driver ready? I did not check the release for a while.

Um, well, it can detect a hard drive, but because of the buggy
kmalloc() it can't do anything really well yet. As soon as I can
figure out what's wrong there (bugs coming in later post), then I can
write a 'write sector' test function, and if that works, start on the
FAT driver.

> Good job anyway.
Well thank you :)

Best regards,

Andrew

[thematrixeatsyou]

Directory layout:
Hmmm, decisions, decisions.

Well, we have comparisons...
/ C:\
/mnt/floppy A:\
/home C:\Documents And Settings (W2K)
C:\Windows\Profiles (W9x)
/usr C:\Program Files
/bin C:\Program Files
C:\Windows

Not sure about these two:
/var C:\Windows
/etc C:\Windows\System

We could have something to give several options for directory layout:
- Windows-style layout: C:\AWOS, /AWOS
- Unix-style layout: /usr/bin, C:\usr\bin
- Custom layout.
That could be a pain to implement though, so I think we should stick
with a new layout. The Windows one's a bit crappy and the Linux one can
be a bit complex for PC newbs.

A proposal:
/
/APPS - applications
./GAMES - games
./DATA - program data
./DEV - development tools: compilers and the like
/SYS - system stuff
./DRV - drivers
./APPS - applications you wouldn't want to mess around with
./DATA - application data
/HOME - profiles
./~/ (replace ~ with username) - user profile
./DOCS - documents

Shells? I'll get back to you on that, I'm rebooting.

[Andrew Wilcox [maintainer]]

thematrixeatsyou wrote:
> We could have something to give several options for directory layout:
> - Windows-style layout: C:\AWOS, /AWOS
> - Unix-style layout: /usr/bin, C:\usr\bin
> - Custom layout.

Yeah that was my first idea.

> A proposal:
Hmm...

> /
> /APPS - applications
> ./GAMES - games

Fun!
> ./DATA - program data
Shouldn't this be under the appropriate folder...e.g. games/data? or
even games/torcs/data?

> ./DEV - development tools: compilers and the like

The thing is, dev is going to make Linux folk think of "devices".

You also forget
./OFFICE
./NET

and I'm sure a few others :)

> /SYS - system stuff
This is kind of like Linux to a point.
> ./DRV - drivers
This would be like ee.ko and ntfs.sys?

> ./APPS - applications you wouldn't want to mess around with

This would be like vmlinuz and kernel32?
> ./DATA - application data
What goes in here?

> /HOME - profiles
So this is like Linux still.

> ./~/ (replace ~ with username) - user profile

Okay.
> ./DOCS - documents
That's somewhat standard, both RedHat and Ubuntu have a "Documents"
subfolder inside the profile.

Don't forget /TEMP, that's, for lack of a better term, international :)

This is still a mess though. Neither Windows vets nor Linux vets will
know what the heck is going on here. And where is /var? /usr/local?
/etc?

Not a bad proposal though.

Best regards,

Andrew

[Andrew Wilcox [maintainer]]

Okay I think I have a new idea.

> We could have something to give several options for directory layout:
> - Windows-style layout: C:\AWOS, /AWOS

no.

> - Unix-style layout: /usr/bin, C:\usr\bin

no.
> - Custom layout.
That's the ticket!

Kind of like mount points, but different.

think of it like this:

# unix folder windows folder
/usr/bin C:\Program Files
/sys C:\AWOS\System386
/etc C:\AWOS\Configuration

and so on...

Just an idea.

>
> Shells? I'll get back to you on that, I'm rebooting.

Still waiting, does it take three days for your computer to reboot???
:D