Sergey Posokhov 3.20.2005
Tradition not trend
Old messages (part II)
Re: Old messages (part II)
Samuel A. Falvo II 3.20.2005
2Yuri: I *DID* read the EDM/2 articles. I found nothing which supports your claim that OS2LDR
makes use of IFS. I found *some* incomplete evidence which supports my claims. If you can post
specific articles which clearly supports your claims, I'd like to see them.
2Yuri: I *DID* read the EDM/2 articles. I found nothing which supports your claim that OS2LDR
makes use of IFS. I found *some* incomplete evidence which supports my claims. If you can post
specific articles which clearly supports your claims, I'd like to see them.
Re: Old messages (part II)
Samuel A. Falvo II 3.20.2005
2Yuri: I think you completely miss the point of my post. The point isn't to get OS/3 running
under Linux, and then being content and happy. The point is to facilitate increased development
activity. Right now, so far as I can tell, development of OS/3 is at a total stand-still. Look at the
News section of your webpage. Except for bringing the site back online, not much has happened
since 2002. It's currently 2005. That's three years without visible progress of any kind. You claim
to have 700 pages of documentation written -- where is it? I don't see it, and Google can't find it.
How am I to know you're telling the truth?
2Yuri: I think you completely miss the point of my post. The point isn't to get OS/3 running
under Linux, and then being content and happy. The point is to facilitate increased development
activity. Right now, so far as I can tell, development of OS/3 is at a total stand-still. Look at the
News section of your webpage. Except for bringing the site back online, not much has happened
since 2002. It's currently 2005. That's three years without visible progress of any kind. You claim
to have 700 pages of documentation written -- where is it? I don't see it, and Google can't find it.
How am I to know you're telling the truth?
Re: Old messages (part II)
Samuel A. Falvo II 3.20.2005
So far as I can tell, OS/2 naturally has major issues with security anyway, as without the LAN Manager
support, you don't have any ACLs of any kind. HPFS is essentially, from the *software* perspective, a
superset of FAT.
So far as I can tell, OS/2 naturally has major issues with security anyway, as without the LAN Manager
support, you don't have any ACLs of any kind. HPFS is essentially, from the *software* perspective, a
superset of FAT.
Re: Old messages (part II)
Samuel A. Falvo II 3.20.2005
2Yuri: "GRUB can't load from unknown filesystem." Wrong. GRUB, as I said, can do a raw sector
read of a kernel or module image. The only requirement is that the chunk of sectors be contiguous
(often doable when installing system files on a clean drive) and immobile (also quite possible by
ensuring the file is read-only and marked with a system file attribute of some kind). This was put
into GRUB expressly *because* it was recognized that GRUB can't be expected to know every single
filesystem in the world. For that matter, GRUB is open source -- why not implement the filesystem
of your choice for GRUB? Only read-only support is used, so it's reading a static image. If the GRUB
folks won't accept the patches, then include your own distribution, built on the base-level GRUB
distro. I just can't see this as being so hard. Meanwhile, trying to get any reasonable information
on OS2LDR (of which I spent upwards of about eight solid hours of pouring through every EDM/2
article I could get my hands on -- that is to say, all of them linked to on their website) was like
pulling teeth, and EVERY article that even mentioned OS2LDR clearly and unambiguously stated,
paraphrased, "There isn't a whole lot of documentation for OS2LDR, so we essentially don't know
how it really works." You can't build an OS on a foundation of smoke and mirrors. Moreover, the
bootloader is used at most once during any OS/2 user session. I just don't see the logic in optimizing
the system to replicate OS2LDR's precise behavior if it's the least executed code in the entire system.
Knuth writes, "Premature optimization is the root of all evil." I believe this to be true based solidly
on personal experience as well. Spending all your time on implementing OS2LDR necessarily means
that SOM doesn't get done, PM doesn't get done, AVIO doesn't get done, etc. You (as a group) need to
make a decision: make it easy to support a wider network of developers allowing you to parallelize
development tasks, or draw from your own (dwindling) supply of potential OS/2 coders (or, more
precisely, coders who also possess a copy of OS/2 to code on), concentrating on a single issue at a
time. These are just my personal observations, and I don't intend to offend anyone (Yuri seems
distinctly upset in his response to my post). But by the same token, the truth really does hurt.
This project has been essentially dead since 2002, minus the "small bugfix"-es and code cleanups.
This leads me to believe that the bulk of the work was done prior to 2002. That's 3 years of
essentially idle time, with no substantive website updates and continual solicitations for contributors.
I'm not going to lie to you: I am very worried about this project's health.
2Yuri: "GRUB can't load from unknown filesystem." Wrong. GRUB, as I said, can do a raw sector
read of a kernel or module image. The only requirement is that the chunk of sectors be contiguous
(often doable when installing system files on a clean drive) and immobile (also quite possible by
ensuring the file is read-only and marked with a system file attribute of some kind). This was put
into GRUB expressly *because* it was recognized that GRUB can't be expected to know every single
filesystem in the world. For that matter, GRUB is open source -- why not implement the filesystem
of your choice for GRUB? Only read-only support is used, so it's reading a static image. If the GRUB
folks won't accept the patches, then include your own distribution, built on the base-level GRUB
distro. I just can't see this as being so hard. Meanwhile, trying to get any reasonable information
on OS2LDR (of which I spent upwards of about eight solid hours of pouring through every EDM/2
article I could get my hands on -- that is to say, all of them linked to on their website) was like
pulling teeth, and EVERY article that even mentioned OS2LDR clearly and unambiguously stated,
paraphrased, "There isn't a whole lot of documentation for OS2LDR, so we essentially don't know
how it really works." You can't build an OS on a foundation of smoke and mirrors. Moreover, the
bootloader is used at most once during any OS/2 user session. I just don't see the logic in optimizing
the system to replicate OS2LDR's precise behavior if it's the least executed code in the entire system.
Knuth writes, "Premature optimization is the root of all evil." I believe this to be true based solidly
on personal experience as well. Spending all your time on implementing OS2LDR necessarily means
that SOM doesn't get done, PM doesn't get done, AVIO doesn't get done, etc. You (as a group) need to
make a decision: make it easy to support a wider network of developers allowing you to parallelize
development tasks, or draw from your own (dwindling) supply of potential OS/2 coders (or, more
precisely, coders who also possess a copy of OS/2 to code on), concentrating on a single issue at a
time. These are just my personal observations, and I don't intend to offend anyone (Yuri seems
distinctly upset in his response to my post). But by the same token, the truth really does hurt.
This project has been essentially dead since 2002, minus the "small bugfix"-es and code cleanups.
This leads me to believe that the bulk of the work was done prior to 2002. That's 3 years of
essentially idle time, with no substantive website updates and continual solicitations for contributors.
I'm not going to lie to you: I am very worried about this project's health.
Re: Old messages (part II)
Yuri Prokushev 3.21.2005
2Samuel: Can GRUB load from network? OS2LDR can do it. Using MicroFS. Small peace of code and
information at http://www.edm2.com/0705/freeldr/freeldr.html. More info at
http://www.edm2.com/0701/warpboot.html. According miss the point of your post. It can be
happened easely. English not my native language . According documentation. Ask Sergey about it
(BTW, it's in Russian Don't know about English version). Next issue. Yes, project in stognation.
And only Sergey seems to know which kernel is preferred to use as base. Actually, before start
implement DOSCALLS interface we need to greate correct loading mechanizm. OS2LDR not requires
to have continous block to load. IFS will do all job for it. In short. Logic is following: IFS boot code
(yes, IFS creates it's own boot code) loads OS2LDR and points entry points for MicroFSD which can read
only from root of FS. OS2LDR loads kernel and call it. Actually, IFS can be placed in any place (boot
sector, netcard ROM, etc.). But it's allows to load things as we need from place we need. Yes, we can
use GRUB or something else. But we have good mechanizm of loading. Really, OS2LDR is also (as
mentioned abose) some sort of microkernel. Actually, OS2LDR can be implemented as L4 microkernel
which will load DOSCALLS library with actual OS/2 API using MicroFSD. Including full IFS loading and
config.sys parsing. Really, we need actual start point (i.e. low-level parts of kernel). Actual problem
is nobody can do it at the present time (no free time, no knowlidges, etc.). As result we still on level
of 2002-2003 year. Only things in progress: API review by Sergey. And now we know ReactOS can be
used as OS/3 kernel If you want really start working on L4 kernel and write DOSCALLS low level API
you always welcome. You can easely contact me and Sergey to discuss according this. Personally, I
want to reimplement SOM Compiler (aka Emitter framework). I have done some research of it and
slowly working on Pascal Emitter implementation (yes, I prefer Pascal ). May be before summer
I'll start working on C Emitter reimplementation.
2Samuel: Can GRUB load from network? OS2LDR can do it. Using MicroFS. Small peace of code and
information at http://www.edm2.com/0705/freeldr/freeldr.html. More info at
http://www.edm2.com/0701/warpboot.html. According miss the point of your post. It can be
happened easely. English not my native language . According documentation. Ask Sergey about it
(BTW, it's in Russian Don't know about English version). Next issue. Yes, project in stognation.
And only Sergey seems to know which kernel is preferred to use as base. Actually, before start
implement DOSCALLS interface we need to greate correct loading mechanizm. OS2LDR not requires
to have continous block to load. IFS will do all job for it. In short. Logic is following: IFS boot code
(yes, IFS creates it's own boot code) loads OS2LDR and points entry points for MicroFSD which can read
only from root of FS. OS2LDR loads kernel and call it. Actually, IFS can be placed in any place (boot
sector, netcard ROM, etc.). But it's allows to load things as we need from place we need. Yes, we can
use GRUB or something else. But we have good mechanizm of loading. Really, OS2LDR is also (as
mentioned abose) some sort of microkernel. Actually, OS2LDR can be implemented as L4 microkernel
which will load DOSCALLS library with actual OS/2 API using MicroFSD. Including full IFS loading and
config.sys parsing. Really, we need actual start point (i.e. low-level parts of kernel). Actual problem
is nobody can do it at the present time (no free time, no knowlidges, etc.). As result we still on level
of 2002-2003 year. Only things in progress: API review by Sergey. And now we know ReactOS can be
used as OS/3 kernel If you want really start working on L4 kernel and write DOSCALLS low level API
you always welcome. You can easely contact me and Sergey to discuss according this. Personally, I
want to reimplement SOM Compiler (aka Emitter framework). I have done some research of it and
slowly working on Pascal Emitter implementation (yes, I prefer Pascal ). May be before summer
I'll start working on C Emitter reimplementation.
Re: Old messages (part II)
Yuri Prokushev 3.21.2005
And now we know ReactOS can be used as OS/3 kernel = And now we know ReactOS can
not be used as OS/3 kernel
And now we know ReactOS can be used as OS/3 kernel = And now we know ReactOS can
not be used as OS/3 kernel
Re: Old messages (part II)
Cristiano Guadagnino 3.21.2005
|=:-O Russian documentation? That's severely limiting the audience... who's gonna translate 700+
pages of russian documentation? I think automated translations services are not mature enough.
Who's gonna benefit from this work if it's done in russian? Sorry to be so pessimistic, but we need
to do something about that. OS/2 coders are already limited in number, if we limit them to the
russian coders we're really in trouble.
|=:-O Russian documentation? That's severely limiting the audience... who's gonna translate 700+
pages of russian documentation? I think automated translations services are not mature enough.
Who's gonna benefit from this work if it's done in russian? Sorry to be so pessimistic, but we need
to do something about that. OS/2 coders are already limited in number, if we limit them to the
russian coders we're really in trouble.
Re: Old messages (part II)
Samuel A. Falvo II 3.21.2005
2Cristiano: Awww, c'mon. If not mature enough, it sure would bring a sense of humor to the community.
2YuriGRUB: Yes, GRUB supports booting over a network interface. I'm not familiar with what protocols it
uses because I never had a need to explore that. But it's definitely doable, and it comes stock with some
network support.
2YuriOS2LDRIFS: THanks for the info. I'll check it out as soon as I grab some free time (shortly; last day
of work for the week!). Your logic for how IFS works with OS2LDR seems sound, but I've honestly never
seen any other OS do this before. Combined with lack of solid docs elsewhere, I didn't even think of this
"inside out" solution. That's actually rather exciting!
2YuriOS2LDRAS-L4: I'll have to think of how to achieve this. L4 assumes it is the top-level, most privileged
piece of code in the running system (literally all other code runs at ring 3, no exceptions). Hence, the
IFS-using parts of the FREELDR (if you'll pardon my use of the term) will be all in 32-bit code, not 16-bit.
Would something like that be acceptable?
2YuriPASCAL: I personally don't like Pascal because I find it's too crippled as a language. My all-time favorite
systems-level AND applications-level programming language is actually a tie between Forth (hence my
FTS/Forth project) and, you guessed it, OBERON. So, that being said, I'll be interested in your Pascal
bindings when it comes time for someone to implement an Oberon-2 compiler for OS/3.
2YuriSOM: I happen to be a *HUGE* proponent of CORBA. I've written my own in-process-only COM
implementation (I love COM too, but CORBA is just SO overwhelmingly better). I could never get my
own IDL compiler working though. I blame it on the lack of documentation for libIDL.so.
2Cristiano: Awww, c'mon. If not mature enough, it sure would bring a sense of humor to the community.
2YuriGRUB: Yes, GRUB supports booting over a network interface. I'm not familiar with what protocols it
uses because I never had a need to explore that. But it's definitely doable, and it comes stock with some
network support.
2YuriOS2LDRIFS: THanks for the info. I'll check it out as soon as I grab some free time (shortly; last day
of work for the week!). Your logic for how IFS works with OS2LDR seems sound, but I've honestly never
seen any other OS do this before. Combined with lack of solid docs elsewhere, I didn't even think of this
"inside out" solution. That's actually rather exciting!
2YuriOS2LDRAS-L4: I'll have to think of how to achieve this. L4 assumes it is the top-level, most privileged
piece of code in the running system (literally all other code runs at ring 3, no exceptions). Hence, the
IFS-using parts of the FREELDR (if you'll pardon my use of the term) will be all in 32-bit code, not 16-bit.
Would something like that be acceptable?
2YuriPASCAL: I personally don't like Pascal because I find it's too crippled as a language. My all-time favorite
systems-level AND applications-level programming language is actually a tie between Forth (hence my
FTS/Forth project) and, you guessed it, OBERON. So, that being said, I'll be interested in your Pascal
bindings when it comes time for someone to implement an Oberon-2 compiler for OS/3.
2YuriSOM: I happen to be a *HUGE* proponent of CORBA. I've written my own in-process-only COM
implementation (I love COM too, but CORBA is just SO overwhelmingly better). I could never get my
own IDL compiler working though. I blame it on the lack of documentation for libIDL.so.
Re: Old messages (part II)
Alex Bervoets 3.22.2005
I'm very happy to see increased activity on this site, at least in this forum. I can understand
Yuri's point of view who wants to have most of OS/2 features recreated. However, given the
facts (IBM is abandoning OS/2, the OS/2 user base shrinks every year and the rather small
number of OS/2 programmers), it seems more opportunistic to take already existing pieces
of open source software that can do the job. Once we have an OS/3 release 1.0 distribution,
we can start rewriting things the way we really like it. So, IMHO, we should use GRUB (or
anything else already existing that fits the job) and concentrate on the more important
pieces of the kernel. If we keep on discussing and trying to rewrite everything from scratch
'the OS/2 way', then we are in 2015 were ReactOS is now.
Second issue : which kernel ? This is a very important design decision, so here we can't simply
say "we'll rewrite it after OS/3 release 1.0". There seems to be some general agreement that
L4 is best fitted for the job. ReactOS appears to lack support for some OS/2 memory models,
but offers another avantage over L4 : NT driver compatibility. How are we going to support a
wide range of hardware with the L4 kernel ? Use OS/2 or linux drivers ? Wouldn't it be better
to fork ReactOS and rewrite parts of it (memory management) ? I'm not a kernel programming
guru, but I'd like to start a debate on the pros and cons of each kernel.
Third issue : programming languages. IMHO, we should stick to the widely used C and C++
languages and also allowing a small amount of x86 assembly language for optimization of
time-critical code. If we're going to attract new developers, then most of them probably
will have C/C++ knowledge, a small number will have Pascal knowledge and practically
nobody will have knowledge of Forth and/or Oberon. However, I wouldn't suggest throwing
away all code and rewriting everything right now. Maintain existing code in your prefered
language and write new things in C/C++. We can always rewrite it.
Fourth issue : documentation in Russian. As this is an international collaboration, I would
suggest translating this in English as soon as possible. IMHO, Sergey should concentrate on
finishing his documentation. We have to find one (preferably more) Russian speaking
person/people who is/are willing to do the translation job.
A final statement : IMHO it should be possible to have an alpha (or even beta) OS/3
distribution by the end of this year. I've seen some postings of some very skilled and
motivated people in this forum recently, so the time has come to implement our
shared ideas and accelerate development of OS/3.
Just my 2 cents. So gentlemen, feel free to comment.
I'm very happy to see increased activity on this site, at least in this forum. I can understand
Yuri's point of view who wants to have most of OS/2 features recreated. However, given the
facts (IBM is abandoning OS/2, the OS/2 user base shrinks every year and the rather small
number of OS/2 programmers), it seems more opportunistic to take already existing pieces
of open source software that can do the job. Once we have an OS/3 release 1.0 distribution,
we can start rewriting things the way we really like it. So, IMHO, we should use GRUB (or
anything else already existing that fits the job) and concentrate on the more important
pieces of the kernel. If we keep on discussing and trying to rewrite everything from scratch
'the OS/2 way', then we are in 2015 were ReactOS is now.
Second issue : which kernel ? This is a very important design decision, so here we can't simply
say "we'll rewrite it after OS/3 release 1.0". There seems to be some general agreement that
L4 is best fitted for the job. ReactOS appears to lack support for some OS/2 memory models,
but offers another avantage over L4 : NT driver compatibility. How are we going to support a
wide range of hardware with the L4 kernel ? Use OS/2 or linux drivers ? Wouldn't it be better
to fork ReactOS and rewrite parts of it (memory management) ? I'm not a kernel programming
guru, but I'd like to start a debate on the pros and cons of each kernel.
Third issue : programming languages. IMHO, we should stick to the widely used C and C++
languages and also allowing a small amount of x86 assembly language for optimization of
time-critical code. If we're going to attract new developers, then most of them probably
will have C/C++ knowledge, a small number will have Pascal knowledge and practically
nobody will have knowledge of Forth and/or Oberon. However, I wouldn't suggest throwing
away all code and rewriting everything right now. Maintain existing code in your prefered
language and write new things in C/C++. We can always rewrite it.
Fourth issue : documentation in Russian. As this is an international collaboration, I would
suggest translating this in English as soon as possible. IMHO, Sergey should concentrate on
finishing his documentation. We have to find one (preferably more) Russian speaking
person/people who is/are willing to do the translation job.
A final statement : IMHO it should be possible to have an alpha (or even beta) OS/3
distribution by the end of this year. I've seen some postings of some very skilled and
motivated people in this forum recently, so the time has come to implement our
shared ideas and accelerate development of OS/3.
Just my 2 cents. So gentlemen, feel free to comment.