OS Development
James Earl
To get rid of that discouraging Subject "New OS? Don't try it," I
thought this one might be a bit more positive.
As I have said, I think, at least the GUI side of the OS should be very
clean and pleasant to the eye. "GUI side" brings up a question...
should it have no command line side, and be just like the MacOS? I
personally like how unix type systems are setup, in that the user has a
choice whether or not he/she runs the GUI interface (XFree86 in this
case).
There are probably millions of questions that have to be answered not
only before developing an OS, but as you go. Like, figuring out whether
having the GUI interface run on top of the shell is a performance
hinderance?
In terms of money involvement with developing a new OS, I think it
should be almost non-existant. I think the only profit that should be
made, is in the distribution of the product. To be able to develop an
OS, I think you would need some other form of income, or be young enough
that you still live at home (like me).
George C. Lindauer
James Earl (je...@lis.ab.ca) wrote:
: To get rid of that discouraging Subject "New OS? Don't try it," I
: thought this one might be a bit more positive.
: There are probably millions of questions that have to be answered not
: only before developing an OS, but as you go. Like, figuring out whether
: having the GUI interface run on top of the shell is a performance
: hinderance?
:
: In terms of money involvement with developing a new OS, I think it
: should be almost non-existant. I think the only profit that should be
: made, is in the distribution of the product. To be able to develop an
: OS, I think you would need some other form of income, or be young enough
: that you still live at home (like me).
I would probably do like the amiga... have gui capable of shelling to
a command line. Of course windows does the same thing... the primary
difference being you could do meaningful stuff on an amiga wiht 512K of RAM
whereas windows needs 16MB. Does that tell you something, or what?
I'm thinking about doing an OS (actually I did a really simple one already,
56K with the debugger built in). I want to use C++... I've never
designed an object-oriented OS before...
David
Michael Hobbs
gcli...@starbase.spd.louisville.edu (George C. Lindauer) wrote:
>I'm thinking about doing an OS (actually I did a really simple one already,
>56K with the debugger built in). I want to use C++... I've never
>designed an object-oriented OS before...
Not to flame or anything, but object-oriented language !=
object-oriented OS. I could build a fabulously monolithic program
using C++. I could also build a fabulously object-oriented OS using
assembly.
Michael Hobbs
Szu-Wen Huang
Michael Hobbs (sha...@datacoreeng.com) wrote:
I'd suggest whoever wants to try first consult with a French attempt
called "Chorus". I've never used it (or even seen it), but according
to reports I have read it suffers from performance problems. I don't
remember a great deal more than this, but surely this is a caveat for
the OOOS (heh) designer to watch out for.
Stewart McDonald
On Thu, 5 Sep 1996, Michael Hobbs wrote:
> >I'm thinking about doing an OS (actually I did a really simple one already,
> >56K with the debugger built in). I want to use C++... I've never
> >designed an object-oriented OS before...
>
> Not to flame or anything, but object-oriented language !=
> object-oriented OS. I could build a fabulously monolithic program
> using C++. I could also build a fabulously object-oriented OS using
> assembly.
Not to mention that an os that is oo from the ground up would be sooooooo
slow. And it'd be more like writing an oo language than using one.
Cia0, Joker/JAM Australia
Samuel A. Falvo II
Test message to test posting ability of my newsreader. Sorry for
posting here, but this group is quick and convenient for me....
Samuel A. Falvo II
Stewart McDonald <smcd...@pcug.org.au> wrote:
>Not to mention that an os that is oo from the ground up would be sooooooo
>slow. And it'd be more like writing an oo language than using one.
Not true at all. If you use C++'s virtual function tables, your code
becomes a call to an indirect vector, which is FASTER than an
interrupt call on an Intel processor (especially in protecte mode!).
In this case, if you were to write code in C++, odds are likely that
your code would actually speed up slightly in some instances, and
would be about the same speed most of the time anyway.
That's why C++ gained far more popularity than Objective-C: it uses as
much of the native CPU for implementing object orientivity as
possible, whereas objective-C is more of an extension to a monolithic
OS, and thus, is slower (but more flexible in some instances).
Samuel A. Falvo II
>> >I'm thinking about doing an OS (actually I did a really simple one already,
>> >56K with the debugger built in). I want to use C++... I've never
>> >designed an object-oriented OS before...
Hey Mike, why not put it up on FTP or otherwise make it available to
others? Just curious... ;-) {making my own OS too}
Sean Aschen
>
>
>On Thu, 5 Sep 1996, Michael Hobbs wrote:
>
>> >I'm thinking about doing an OS (actually I did a really simple one already,
>> >56K with the debugger built in). I want to use C++... I've never
>> >designed an object-oriented OS before...
>>
>> Not to flame or anything, but object-oriented language !=
>> object-oriented OS. I could build a fabulously monolithic program
>> using C++. I could also build a fabulously object-oriented OS using
>> assembly.
>
>Not to mention that an os that is oo from the ground up would be sooooooo
>slow. And it'd be more like writing an oo language than using one.
>
>Cia0, Joker/JAM Australia
>
What kind of compiler are you using? C++ is less inefficient than one
would think.
Michael Hobbs
fal...@borg.com (Samuel A. Falvo II) wrote:
>>> >I'm thinking about doing an OS (actually I did a really simple one already,
>>> >56K with the debugger built in). I want to use C++... I've never
>>> >designed an object-oriented OS before...
>Hey Mike, why not put it up on FTP or otherwise make it available to
>others? Just curious... ;-) {making my own OS too}
Sorry, but that was George C. Lindauer who originally wrote that
message. My OS is a totally different beast :-)
I'm beginning to believe that there exists at least 1 OS for each
person who reads this group...
Michael Hobbs
George C. Lindauer
Michael Hobbs (sha...@datacoreeng.com) wrote:
: fal...@borg.com (Samuel A. Falvo II) wrote:
:
: >>> >I'm thinking about doing an OS (actually I did a really simple one already,
: >>> >56K with the debugger built in). I want to use C++... I've never
: >>> >designed an object-oriented OS before...
Hi folks.
Time to advertise again... like I've said before here and to the free-dos
group, what I want to do is make a 32-bit DOS type thing. I think between
linux and windows, all us really low-level folk are getting crowded out
of the 32-bit world unless we go from scratch every time or decide to
depend on VCPI or DPMI. What we need is a really simple OS that will allow
us to do 32-bit programming without always having to play with the details
of pmode.
I think a lot of the features of DOS are necessary. In addition I want
to add multitasking, device drivers that are loadable and unloadable
(sort of like a TSR in DOS only with more built-in support). I'm also
going to throw in a unique character set a friend of mine thought up...
has lots of neet characters. So the wish list is like this:
small and simple.
Coherent user interface (probably through interrupts)
multitasking
memory managment
file system
backwards compatability with DOS (through VCPI shell).
loadable device drivers.
Of course it should have development tools, and an editor. Maybe a few
utilities.
I've actually written most of the pieces at one time or another... the major
things I'm missing are an assembler and an editor. Plus I'm going to rewrite
the whole OS from scratch because the current version has too much
real-mode support and no support for loadable device drivers or DOS.
If anyone has any comments or things they think should be in it let me know...
but you needn't tell me how foolish I am because I could alwyas buy the linux
CDs
David
George C. Lindauer
Michael Hobbs (sha...@datacoreeng.com) wrote:
: fal...@borg.com (Samuel A. Falvo II) wrote:
:
: >>> >I'm thinking about doing an OS (actually I did a really simple one already,
: >>> >56K with the debugger built in). I want to use C++... I've never
: >>> >designed an object-oriented OS before...
: >Hey Mike, why not put it up on FTP or otherwise make it available to
: >others? Just curious... ;-) {making my own OS too}
:
: Sorry, but that was George C. Lindauer who originally wrote that
: message. My OS is a totally different beast :-)
:
: I'm beginning to believe that there exists at least 1 OS for each
: person who reads this group...
: Michael Hobbs
YEah really... I'm about to rewrite mine, I talked to the TERSE guy so you
might see a terse one up on the net soon... Mine has been available
for over a year via FTP. I didn't advertise for much of that time
because early users were getting problems which I couldn't duplicate
because of different hardware. I finally found a computer that busted my
program though, so the latest version should work on nearly any computer
unless you have too little memory. I'm not advertising it in general
because I'm going to do a complete rewrite and add lots of new features...
The only time I really mention it is when someone wants to see BIOS
drivers... I handle every BIOS device except the hard disk and then I
threw in the mouse too. It's a very comprehensive program, good for
learning all sorts of stuff about pmode and the bios and mutltitasking
and so on. The site is:
ftp.std.com:/pub/os-code/lsddl150.zip.
While you are there you might pick up emu86.zip- which is a V86 shell
demo. Also, if anyone wants a (relatively) simple C compiler with
sources for their 32-bit OS, you can pick up ccdl122.zip off that same
site. Full sources, both for the compiler and the run-time libraries.
All you have to do is get an assembler linker and librarian- and bang you
have your own 32-bit development system. I have sources for everything
but the assembler so far... it's on my list of things to do but I haven't
made time yet. Too busy playing with the SCSI drive I guess...
David
JK
In article <Pine.SOL.3.91.960912004430.10233G-100000@supreme> Stewart McDonald <smcd...@pcug.org.au> writes:
> Tell me, what do people have to do to get a newsgroup started, as I
> believe an os development group would be much better than sifting through
> these groups all the time..... Just a thought.
comp.os.research?
There you probably can get some professional help too...
David Cox
Samuel A. Falvo II wrote:
>
> >> >I'm thinking about doing an OS (actually I did a really simple one already,
> >> >56K with the debugger built in). I want to use C++... I've never
> >> >designed an object-oriented OS before...
>
> Hey Mike, why not put it up on FTP or otherwise make it available to
> others? Just curious... ;-) {making my own OS too}
Sam,
I have also started to write systems code using Borland C++ version 4.52.
I have used TASM to create a start up module that can be linked with
C++ code compiled with the 32 bit compiler. This has been an interesting
learning experience for me because the 32 bit compiler is used (normally)
to create 32 bit Windows programs that run under NT, 95, or Win32s.
However, I have come up with a simple recipe for using this compiler
to create 32 bit program that can be called from DOS. When those
programs end they gracefully exit back to DOS.
The recipe works like this:
Using the command line compiler, bcc32, compile your C++ files to object
files. As usual be sure one of them contains main().
Then link with tlink /3 the startup module and all the C++ files. Note
that you do not use tlink32. Tlink32 produces executables that are in
the NE (New Executable format) and not the DOS format. However, tlink /3
will produce a DOS executable with 32 bit segments. Tlink alone without
the /3 option won't work. Without /3 tlink complains about the object
modules containing 32 bit segments while /3 overrides this behavior.
The start up module is both simple and complex. It is simple because it
less than 200 lines long including extensive comments. It is complex
because to write it required an understanding of global descriptor tables
and how to use the assembler to declare 32 bit segments using the SEGMENT
keyword. In particular I found the use32 option to be very poorly
documented. It also required an understanding of what is happening
when one jumps from 16 bit to 32 bit segments and back again.
To clarify all of these issues I am writing a detailed paper complete with
the startup code. The beauty of the result is that the C++ programmer
can now work exclusively in C++ to produce 32 bit programs (including
operating systems) that can be launched from DOS. If certain precautions
are taken, those programs can also gracefully return to DOS.
Now, this startup code and the paper I am writing are definitely not for
everyone. The seasoned systems programmer will view it as too elementary
to even bother reading it. However, I am writing it for folks like me --
novices who are looking for good documentation on how to do 32 bit systems
programming. It won't explain everything but it will get the novice
started.
Well, just wanted to pass this along.
Have a good day.
Dave
David Cox
David Cox
Stewart McDonald
On Mon, 9 Sep 1996, Samuel A. Falvo II wrote:
> That's why C++ gained far more popularity than Objective-C: it uses as
> much of the native CPU for implementing object orientivity as
> possible, whereas objective-C is more of an extension to a monolithic
> OS, and thus, is slower (but more flexible in some instances).
No it's not. C++ will compile c code with no modifications, which is why
it hammered obj-c. Just as windows 95 sells more than os/2. Simple.
Joker
Stewart McDonald
On Tue, 10 Sep 1996, Sean Aschen wrote:
> What kind of compiler are you using? C++ is less inefficient than one
> would think.
Not me, I'm still at an asm level yet, much better for a small kernel.
I'm not doing oo, but it is too much overhead for a few years....
Joker
Stewart McDonald
On Mon, 9 Sep 1996, Samuel A. Falvo II wrote:
> >> >I'm thinking about doing an OS (actually I did a really simple one already,
> >> >56K with the debugger built in). I want to use C++... I've never
> >> >designed an object-oriented OS before...
>
> Hey Mike, why not put it up on FTP or otherwise make it available to
> others? Just curious... ;-) {making my own OS too}
Tell me, what do people have to do to get a newsgroup started, as I
believe an os development group would be much better than sifting through
these groups all the time..... Just a thought.
My os should be public beta (no software, probably) in a month or two.
Nothing special, but if you guys see it, it works. Still under
construction at the moment, tho.
Cia0, Joker/JAM Australia
Stewart McDonald
On Tue, 10 Sep 1996, Michael Hobbs wrote:
> I'm beginning to believe that there exists at least 1 OS for each
> person who reads this group...
> Michael Hobbs
Probably......
Shit, I'm doin' it 2......
Joker
Schol-R-LEA
Stewart McDonald <smcd...@pcug.org.au> was baying at the moon about:
I second the motion. Who wants to write the CFV for
[alt|comp].os.design ? I'd suggest the alt.* to start, as there is
some overlap with comp.os.research (tho' that is mostly a theory
group). We can move to a comp.* group later if we choose.
Schol-R-LEA;2, ELF BiWM MGT POEE JAM LCF GS SMOF KCO
First Speaker, Last Eristic Church of Finagle and Holy Bisexuality
Anybody for President '96!|| Trouble rather the tiger in his lair
http://www.bpp.com/whig/ || than the Scholar amongst his books
james earl
Schol-R-LEA <jos...@value.net> wrote in article
<5188hu$d...@vnetnews.value.net>...
> Stewart McDonald <smcd...@pcug.org.au> was baying at the moon about:
>
> I second the motion. Who wants to write the CFV for
> [alt|comp].os.design ? I'd suggest the alt.* to start, as there is
> some overlap with comp.os.research (tho' that is mostly a theory
> group). We can move to a comp.* group later if we choose.
I definitely think this should be done. However, first, I personally think
it should be under "comp" and should end in "development" or "dev", since
subject: development can cover everything, including design.
George C. Lindauer
james earl (je...@lis.ab.ca) wrote:
:
:
: Schol-R-LEA <jos...@value.net> wrote in article
How about:
comp.os.homebrew.develop
I also thought about
comp.os.osdevelop
but I like the first one better. I'll trot off and find out what needs to
be done...
David
Carl Laurence Gonsalves
In article <Pine.SOL.3.91.960912004301.10233F-100000@supreme>,
>> much of the native CPU for implementing object orientivity as
>> possible, whereas objective-C is more of an extension to a monolithic
>> OS, and thus, is slower (but more flexible in some instances).
>
>No it's not. C++ will compile c code with no modifications, which is why
>it hammered obj-c. Just as windows 95 sells more than os/2. Simple.
Your reasoning doesn't fit with reality. Objective-C is a superset of ANSI-C,
while C++ is *not* a superset of ANSI C. Take the following ANSI C
program:
/* begin */
#include <stdio.h>
int main(){
int private = 0;
puts( "Hello World!" );
return private;
}
/*end */
This is also a legal Objective-C program, but is not a legal C++ program.
If you look at the extensions Objective-C adds to C you'll see (argh) that
they were careful to avoid adding any new identifiers. Essentially every
bit of "new stuff" in Objective-C is a syntax error in ANSI-C.
C++ on the other hand has a bunch of new reserved words (private,
protected, class, this, just to name a few), the new style comments (which
can interfere with certain rare cases), and a slightly different set of
rules regarding visibility of names and structs. In essence, the
additional names that are added to the namespace when creating a struct or
enum can cause other names to become hidden. Try the following in both C
and C++:
/* begin */
typedef int foo;
main(){
struct foo { char *p; };
foo myFoo = 5;
return 0;
}
/* end */
Again, it'll compile fine in C and Objective-C, but not in C++.
Finally, C++ *needs* prototypes. C and Objective-C don't.
The reasons C++ is more popular I would imagine have something to do with
the fact that many people haven't even heard of Objective-C. There are also
very few Objective-C compilers available... the only one I know of is gcc
(GNU). And a lot of companies simply won't use GNU tools...
Objective-C and C++ are not mutually exclusive, BTW. There is
"Objective-C++"... ie: C++ with Objective-C's extensions. I think there's a
way to get gcc to compile this, but I've never tried it.
--
Carl Laurence Gonsalves - clgo...@undergrad.math.uwaterloo.ca
Computer Science, University of Waterloo
http://www.undergrad.math.uwaterloo.ca/~clgonsal/
http://www.csclub.uwaterloo.ca/~clgonsal/
Schol-R-LEA
gcli...@starbase.spd.louisville.edu (George C. Lindauer) was baying
at the moon about:
>james earl (je...@lis.ab.ca) wrote:
>:
>:
>: Schol-R-LEA <jos...@value.net> wrote in article
>: <5188hu$d...@vnetnews.value.net>...
>: > Stewart McDonald <smcd...@pcug.org.au> was baying at the moon about:
>: >
>: > I second the motion. Who wants to write the CFV for
>: > [alt|comp].os.design ? I'd suggest the alt.* to start, as there is
>: > some overlap with comp.os.research (tho' that is mostly a theory
>: > group). We can move to a comp.* group later if we choose.
>:
>: I definitely think this should be done. However, first, I personally think
>: it should be under "comp" and should end in "development" or "dev", since
>: subject: development can cover everything, including design.
>:
>How about:
>comp.os.homebrew.develop
>I also thought about
>comp.os.osdevelop
>but I like the first one better. I'll trot off and find out what needs to
>be done...
OK, let's have an informal CFV on the name :
1) comp.os.design
2) comp.os.development
3) alt.comp.os.design
4) alt.comp.os.homebrew
5) comp.os.homebrew.develop
6) comp.os.osdevelop
I personally am voting for #4, on the grounds that it would take mcuh
less time to newgroup an alt.* group; eventually, if the group is
popular, we can move to comp.os.development (which makes a good
complement to comp.os.research ). #5 probably couldn't pass, as there
are plenty of anal types who would claim that it looks like a
development for a *specific* OS called Homebrew (if you dont beleieve
me, look in the alt.newsgroup.announce archive for the debate on
alt.net.vikings to see what I mean). #6 is redundant, and would also
probably not pass for that reason (in fact, I was wonderinf if that
was a typo, and you meant to say comp.os.develop ).
If no one else wants to, I'll write a CFV as soon as we've settled on
a name.
james earl
Schol-R-LEA wrote:
>
> OK, let's have an informal CFV on the name :
>
> 1) comp.os.design
> 2) comp.os.development
> 3) alt.comp.os.design
> 4) alt.comp.os.homebrew
> 5) comp.os.homebrew.develop
> 6) comp.os.osdevelop
>
> I personally am voting for #4, on the grounds that it would take mcuh
> less time to newgroup an alt.* group; eventually, if the group is
> popular, we can move to comp.os.development (which makes a good
> complement to comp.os.research ). #5 probably couldn't pass, as there
> are plenty of anal types who would claim that it looks like a
> development for a *specific* OS called Homebrew (if you dont beleieve
> me, look in the alt.newsgroup.announce archive for the debate on
> alt.net.vikings to see what I mean). #6 is redundant, and would also
> probably not pass for that reason (in fact, I was wonderinf if that
> was a typo, and you meant to say comp.os.develop ).
>
> If no one else wants to, I'll write a CFV as soon as we've settled on
> a name.
If we can... there's no reason not to strive for the best, or most
preferred. #2 seems to be the most understandable, self-explanitory,
and general topic name (to me). #2 describes what is to be discussed...
nothing more, and nothing less.
I am not familiar with what a "CFV" is?
Vadim Zeitlin
In article <51eu48$m...@vnetnews.value.net>,
jos...@value.net (Schol-R-LEA) wrote:
>>OK, let's have an informal CFV on the name :
>>
>>1) comp.os.design
>>2) comp.os.development
>>3) alt.comp.os.design
>>4) alt.comp.os.homebrew
>>5) comp.os.homebrew.develop
>>6) comp.os.osdevelop
>>
>>I personally am voting for #4, on the grounds that it would take mcuh
>>less time to newgroup an alt.* group
Sure, but on the other hand there are a lot of people who don't
have access to alt.* hierarchy, so, personally, I'd like it to be
in comp (2, for example).
VZ
George C. Lindauer
Schol-R-LEA (jos...@value.net) wrote:
: gcli...@starbase.spd.louisville.edu (George C. Lindauer) was baying
: at the moon about:
:
: >:
: >:
: OK, let's have an informal CFV on the name :
:
: 1) comp.os.design
: 2) comp.os.development
: 3) alt.comp.os.design
: 4) alt.comp.os.homebrew
: 5) comp.os.homebrew.develop
: 6) comp.os.osdevelop
: If no one else wants to, I'll write a CFV as soon as we've settled on
: a name.
Yeah, number 4 is fine.
If you want to write a CFV go ahead. I did lots of research and found
an emali place that helps with getting new groups into the big 8... and
they sent me docs on the process. It looks like a real hassle- I was willing
to do it but if someone else would rather I won't mind giving it up one
little bit :).
David
James R. Ashley
Stewart McDonald wrote:
>
> On Thu, 5 Sep 1996, Michael Hobbs wrote:
>
> > >I'm thinking about doing an OS (actually I did a really simple one already,
> > >56K with the debugger built in). I want to use C++... I've never
> > >designed an object-oriented OS before...
> >
> > object-oriented OS. I could build a fabulously monolithic program
> > using C++. I could also build a fabulously object-oriented OS using
> > assembly.
>
> Not to mention that an os that is oo from the ground up would be sooooooo
> slow. And it'd be more like writing an oo language than using one.
>
> Cia0, Joker/JAM Australia
That depends on how you approach the OS. If you just start off from
ground zero, doing everything in SmallTalk (or C++, or whatever),
that would tend to slow things down. But, I wonder how all those
look-up tables would compare with, say, MS' spaghetti code for 95. I
personally don't believe they would be much worse.
This could actually be a major extension of the HLL vs. asm thread
that's been running here for so long.
Personally, I think your best bet is to write the code in a HLL, then
figure out where you spend most of your time, and waste most of your
space. If you're writing an OS, a big chunk of your drivers are gonna
be in ASM. You can still use HLL wrappers and inline asm. Anyway. Fix
your bugs. Then figure out what needs optimizing, and do so. Then
fix your new bugs. Repeat, until optimization is irrelevant. Release,
then start revising.
(Hehehe, based on recent discussions, I'll never make it as a real
programmer--I forgot to mention the fact that the marketing dept.
is breathing down your neck, telling you that a few little bugs don't
matter, and we'd really like to see 'this' feature added...)
Pardon the side comment, but *that* particular attitude is a major
reason that most products today are such total garbage. When I run my
computer, I'm looking for a reliable product. Period. End of paragraph.
Then I start complaining about the fact that it's too slow. (Unless
I'm running windows, like I am now, this faze usually hits about the
time that my floppy drive light turns on).
Finally, if the software I have right now doesn't support my needs, I
start looking for an extension. I *love* the Unix philosophy of one
small program, one small feature. I would much rather play with a 10K
text formatter than change $400, 400M word processors.
But, then, silly me, what do I know? Most people wouldn't have a clue
about how their computers worked unless everything came in one simple
bundle. And Heaven Forbid we (I mean you--I'm just a hobbyist) ask any-
one to actually get a clue re: How Your Computer Actually Works.
Oops. It looks like I found a soap box. Sorry.
Anyway. The topic of this discussion was actually:
If you're designing an OS from the ground up, is OOP, from the
start, a bad thing?
So far, the opinions seem to be:
1) Yes. Exceptionally slooooow
2) No. Not too slow, and you can speed it up later.
Thoughts?
jimerthy
p.s. This doesn't mean I'm taking my own advice, just for the record :)
Stewart McDonald
On Sat, 14 Sep 1996, Schol-R-LEA wrote:
> OK, let's have an informal CFV on the name :
>
> 1) comp.os.design
> 2) comp.os.development
> 3) alt.comp.os.design
> 4) alt.comp.os.homebrew
> 5) comp.os.homebrew.develop
> 6) comp.os.osdevelop
7) alt.hobby.osdev?
Whaddaya think? This shows that it is for homebrew os' but cannot be
though of as some os named homebrew.
Cia0, Joker/JAM Australia
Samuel A. Falvo II
Stewart McDonald <smcd...@pcug.org.au> wrote:
First of all, I'm not Stewart McDonald... :)
>No it's not. C++ will compile c code with no modifications, which is why
And objective-C won't? I don't know about you, but EVERY Objective-C
"compiler" I've seen is merely a preprocessor which converts
Objective-C into native C, and passes it to a standard C compiler.
Well, guess what... if a program doesn't use Objective-C constructs in
it, the preprocessor doesn't DO anything to the source code, and thus,
compiles (again) without a hitch.
C++, on the other hand, has a very DIFFICULT time compiling C code,
especially when it encounters some of my old C header files, which
often include a typedef char bool; statement in it (guess what: bool
is RESERVED in C++, but not in Objective-C or C).
>it hammered obj-c. Just as windows 95 sells more than os/2. Simple.
Exactly how one OS outsells another OS is relavent to this topic
escapes me.
As you can see, Joker, the issues here aren't quite so "simple".
Furthermore, I ask that you keep your arrogent attitude to yourself.
Stewart McDonald
On Mon, 16 Sep 1996, James R. Ashley wrote:
> Anyway. The topic of this discussion was actually:
> If you're designing an OS from the ground up, is OOP, from the
> start, a bad thing?
>
> So far, the opinions seem to be:
> 1) Yes. Exceptionally slooooow
> 2) No. Not too slow, and you can speed it up later.
>
> Thoughts?
Not too slow is still too slow. You don't _need_ oo in an operating
system full stop. In a user interface, it should still be optional, like
OLE (or what ole wants to be, anyhoo). A teency bit of oo (like writing
to devices as files, like even dos can) is good, but it should only be
there if it enhances the operating system, which IMHO most of it
wouldn't. We really don't need object oriented operating systems, and as
it (and mutlimedia) are no longer buzzwords, everything that matters is
now the internet, and that's the thing everybody wants built into their
OS, which of course is another thing that is better tacked on that built in.
Ahhhh, if only they saw the simple real internet, like the newsgroups on
tv, instead of glorified www pages, and java, and information
superhighway (as if)..... Anyway I'm rambling now, aren't I?
Joker
Michael Hobbs
jos...@value.net (Schol-R-LEA) wrote:
>OK, let's have an informal CFV on the name :
>1) comp.os.design
>2) comp.os.development
>3) alt.comp.os.design
>4) alt.comp.os.homebrew
>5) comp.os.homebrew.develop
>6) comp.os.osdevelop
2 things: Since this will be an OS that runs on Intel-based PC's, I
think the platform ought to be evident in the group name. Second, the
comp.* hierarchy is a more prestigious hierarchy, therefore it is to
be preferred. The alt.* hierarchy is not carried by many news servers
because it is deemed by some as having frivolous groups.
Michael Hobbs
Schol-R-LEA
Stewart McDonald <smcd...@pcug.org.au> was baying at the moon about:
>On Mon, 16 Sep 1996, James R. Ashley wrote:
>> Anyway. The topic of this discussion was actually:
>> If you're designing an OS from the ground up, is OOP, from the
>> start, a bad thing?
>>
>> So far, the opinions seem to be:
>> 1) Yes. Exceptionally slooooow
>> 2) No. Not too slow, and you can speed it up later.
>>
>> Thoughts?
>Not too slow is still too slow. You don't _need_ oo in an operating
>system full stop. In a user interface, it should still be optional, like
>OLE (or what ole wants to be, anyhoo). A teency bit of oo (like writing
>to devices as files, like even dos can) is good, but it should only be
>there if it enhances the operating system, which IMHO most of it
>wouldn't. We really don't need object oriented operating systems, and as
>it (and mutlimedia) are no longer buzzwords, everything that matters is
>now the internet, and that's the thing everybody wants built into their
>OS, which of course is another thing that is better tacked on that built in.
Despite what many think, while it is true that OO has a certain amount
of inefficiency built into it, it is not the main cause of the
software bloat of recent years. In fact, it seems to be as much from
*incorrect* use of OO languages, esp. C++ ; programmers who aren't
comfortable with OOP are being told to write 'object orientation code'
by management, a command they often satisfy by making it *look* like
they used all the fancy new 'paradigmization' but which underneath is
a poorly constructed form of the same type of code they've always
written. Similar problems occured in the '60s and early '70s when the
big push for structured programming began, hence the old saw about
writing FORTRAN code in any language. For a new technique to work you
actually have to understand and use it, and use it for what its
suitable for at that.
Besides, Grosch's Law still applies, as does the generalized version
of Parkinson's. As hardware gets more powerful, programmers naturally
tend to take advantage of it, at the cost of overall efficiency.
As for the efficiency OOP, in 1988 the original port of the
Smalltalk-V environment ran faster on a 286/12 than Multics95 does
today on a P100 for most windowing operations, despite the latter
being mostly hand-coded assembly code... of course, Smalltalk didn't
have legacy code to contend with. Oh, and Golden Common LISP ran
pretty fast too, despite its poor rep at the time, if you were
interested at all in functiional programming.
james earl
> 2 things: Since this will be an OS that runs on Intel-based PC's, I
> think the platform ought to be evident in the group name. Second, the
> comp.* hierarchy is a more prestigious hierarchy, therefore it is to
> be preferred. The alt.* hierarchy is not carried by many news servers
> because it is deemed by some as having frivolous groups.
> Michael Hobbs
We could start with:
comp.os.development
as the general topic, then work towards more specifics like:
comp.os.development.intel
comp.os.development.<whatever>
.oO The Joker Oo.
On Tue, 17 Sep 1996, Samuel A. Falvo II wrote:
> >No it's not. C++ will compile c code with no modifications, which is why
>
> And objective-C won't? I don't know about you, but EVERY Objective-C
> "compiler" I've seen is merely a preprocessor which converts
> Objective-C into native C, and passes it to a standard C compiler.
> Well, guess what... if a program doesn't use Objective-C constructs in
> it, the preprocessor doesn't DO anything to the source code, and thus,
> compiles (again) without a hitch.
>
> C++, on the other hand, has a very DIFFICULT time compiling C code,
> especially when it encounters some of my old C header files, which
> often include a typedef char bool; statement in it (guess what: bool
> is RESERVED in C++, but not in Objective-C or C).
All you people are whinging about the fact that syntactically correct
code wont compile because it uses now reserved keywords. What do you
expect? Please can I have oo installed in this language, but without any
new keywords, just to make it completely impossible to write clear code
that somebody can tell the difference between the parts that are oo and
the parts that are not? How do you propose they should have extended c to
c++ without adding any new keywords?
And since when is it you place to blame me for somebody else's language
anyway?
> >it hammered obj-c. Just as windows 95 sells more than os/2. Simple.
>
> Exactly how one OS outsells another OS is relavent to this topic
> escapes me.
No it's not, because 95 sells more than os2 for the same reasons, it runs
(compiles) all old programs (well, most of them, more than os/2). I'm
sure there are some ansi-c c programs that will take out most c++
compilers, but ansi-c++ was designed with full backwards compatibility in
mind, obj-c wasn't.
> As you can see, Joker, the issues here aren't quite so "simple".
> Furthermore, I ask that you keep your arrogent attitude to yourself.
My attitude is in no way arrogant, just because your opinion differs from
mine. And what the bloody hell does this have to do with OS development
anyway.
Joker
Paul Hsieh
james earl wrote:
> Schol-R-LEA wrote:
> > OK, let's have an informal CFV on the name :
> >
> > 1) comp.os.design
> > 2) comp.os.development
> > 3) alt.comp.os.design
> > 4) alt.comp.os.homebrew
> > 5) comp.os.homebrew.develop
> > 6) comp.os.osdevelop
> >
> preferred. #2 seems to be the most understandable, self-explanitory,
> and general topic name (to me). #2 describes what is to be
> discussed... nothing more, and nothing less.
I second the motion. comp.os.development sounds good to me.
--
Paul Hsieh
qed at chromatic dot com (replace the "at" and "dot")
http://www.geocities.com/SiliconValley/9498
Graphics Programmer
Chromatic Research
What I say and what my company says are not always the same thing
Paul Hsieh
james earl wrote:
> Schol-R-LEA wrote:
> > OK, let's have an informal CFV on the name :
> >
> > 1) comp.os.design
> > 2) comp.os.development
> > 3) alt.comp.os.design
> > 4) alt.comp.os.homebrew
> > 5) comp.os.homebrew.develop
> > 6) comp.os.osdevelop
> >
> If we can... there's no reason not to strive for the best, or most
> preferred. #2 seems to be the most understandable, self-explanitory,
> and general topic name (to me). #2 describes what is to be
> discussed... nothing more, and nothing less.
I second the motion. comp.os.development sound good to me.
Schol-R-LEA
Paul Hsieh <nob...@chromatic.com> was baying at the moon about:
>james earl wrote:
>> Schol-R-LEA wrote:
>> > OK, let's have an informal CFV on the name :
>> >
>> > 1) comp.os.design
>> > 2) comp.os.development
>> > 3) alt.comp.os.design
>> > 4) alt.comp.os.homebrew
>> > 5) comp.os.homebrew.develop
>> > 6) comp.os.osdevelop
>> >
>> If we can... there's no reason not to strive for the best, or most
>> preferred. #2 seems to be the most understandable, self-explanitory,
>> and general topic name (to me). #2 describes what is to be
>> discussed... nothing more, and nothing less.
>I second the motion. comp.os.development sounds good to me.
I received one other vote in favor of (2), and I myself prefer it
despite my concerns about its passing. I have got only one vote each
for alt.comp.os.homebrew and comp.os.homebew.develop and none for the
others specifically. It will take about a week for me to write a CFV
and a rough draft FAQ (again, unless someone with more time can take
those projects), and the voting will remain open until I'm ready to
release them, but for now I will accept comp.os.development as the
newsgroup name.
Brennan Cheung
> I received one other vote in favor of (2), and I myself prefer it
> despite my concerns about its passing. I have got only one vote each
> for alt.comp.os.homebrew and comp.os.homebew.develop and none for the
> others specifically. It will take about a week for me to write a CFV
> and a rough draft FAQ (again, unless someone with more time can take
> those projects), and the voting will remain open until I'm ready to
> release them, but for now I will accept comp.os.development as the
> newsgroup name.
I think that we should have the platform that we are developing for in
there somewhere. I suggest comp.os.development.x86
Mark H E White II
Brennan Cheung wrote:
>
> I think that we should have the platform that we are developing for in
> there somewhere. I suggest comp.os.development.x86
I think a new news group for 'making your own OS' is a great idea.
As far as I can tell 'Schol-R-LEA <jos...@bpp.com>' has unwittingly
taken charge of its starting.
Schol-R-LEA, please tell us what we can do to help get this going.
None of use seem to have much spare time but there seems to be
many of us interested, so we should be able to share the work.
I like the name 'comp.os.development', having a '.x86', '.x68'...
would be nice but, some wish to go multi platform and splitting us
up from the start would make it harder to get the # of votes.
Mark H E White II
Reposting article removed by rogue canceller.
Brennan Cheung
Reposting article removed by rogue canceller.
> I received one other vote in favor of (2), and I myself prefer it
> despite my concerns about its passing. I have got only one vote each
> for alt.comp.os.homebrew and comp.os.homebew.develop and none for the
> others specifically. It will take about a week for me to write a CFV
> and a rough draft FAQ (again, unless someone with more time can take
> those projects), and the voting will remain open until I'm ready to
> release them, but for now I will accept comp.os.development as the
> newsgroup name.
I think that we should have the platform that we are developing for in
George C. Lindauer
Brennan Cheung (gal...@slip.net) wrote:
: > I received one other vote in favor of (2), and I myself prefer it
I'm opposed to that... I thought about it, but I do a lot of 68000
work as well. If I have a general development issue I don't want
to be barred from posting just because 99% of people like the x86 series
for whatever reason. That said, one of my current projects IS an
386 OS...
David
George C. Lindauer
ch...@wiloyee.shnet.org
Stewart McDonald (smcd...@pcug.org.au) wrote:
:
:
:
: > Anyway. The topic of this discussion was actually:
: > If you're designing an OS from the ground up, is OOP, from the
: > start, a bad thing?
: >
: > So far, the opinions seem to be:
: > 1) Yes. Exceptionally slooooow
: > 2) No. Not too slow, and you can speed it up later.
: >
: > Thoughts?
if you base the OS on C++, you are dependent to one implementation of C++
since different implementations are not binary compatible (virtal function
tables, exceptions, multiple inheretence, constructor calls,...)
i guess the same is for objective C and any other object orientated
language. In fact pure C is not really binary compatible, but most
compilers have many options that allow the compiler to behave binary
compatible.
it is a bad idea to base an operating system on a certain implementation
of a language. perhaps it is a bad idea to base an OS on a certain language
at all.
If you need stub-routines to call OS functions, most of the OOP beauty is
lost. i fact, in this case you could as well use C as language and use
OO design methods. to link this with a real OO language use wrapper classes.
using inline functions, allmost no speed should be lost.
Or implement OS and Applications with an OO language and use a C interface.
then you need wrappers on both sides of the interface.
in all cases, a clear line between OS and API is allways helpfull. Writing
a new OS is a very tempting hobby (i tried myself), but an OS without
applications is uninteresting. I see no reason why multiple OS shouldn't
have the same API, and you can allways port your API to Windows or Linux
if you want a wider audience for your applications.
dierk "chaos" ohlerich
picmatic
Vote me in too.
Brian