unite to make an OS

[kerravon]

Tell me about it! I often end up with no energy for coding because I've put so much into social things, sometimes including posting here.

I have an idea how to unite several lone programmers. You need to port hundreds of interesting applications from different authors to your OS. Applications should be unique, little known, well-written, not be copies of their ancestors, work well, etc.

I am interested in this social idea. But immediate questions are:

1. What's wrong with just joining Linux?

2. Are you trying to achieve something out of this? Or is it just to have a social club?

3. Who is going to do the work of porting hundreds of interesting (to who?) applications to "your OS" (which OS is that?).

I also wonder if anyone has tried to do this: to connect a lot of single people, weak in terms of business, and get a qualitative and quantitative advantage over commerce. By analogy with the film "Free Reiner".

Can you provide a link to the film? I saw a TV series "Free Rein" which didn't seem relevant.

I did this at university: in one team project, I created a team of classmates with the lowest social rating. The result was bad - the ******* teacher disbanded the team. But for me, working in it was much more productive than working in a team of classmates with a high social rating.

Conclusion: you need to form a society of those who are much less socialized than you and become their leader.

I'm certainly interested a "society" of misfits or whatever you want to call this. I noticed in the osdev discord that a lot of OS developers had been "diagnosed" with "autism". I looked that up and it I suspect it is just a stupid misdiagnosis. The description is something like "people who don't know that certain behaviors are inappropriate in a social setting", but I suspect that the correct diagnosis of people with the skills to write an OS is "people who know damn well that certain behaviors are inappropriate in a social setting, but don't give a **** about the opinions of lightweight dipshits".

[Alexey1994]

1. What's wrong with just joining Linux?

Not interested in developing drivers endlessly

2. Are you trying to achieve something out of this? Or is it just to have a social club?

It's just an idea, the result is not predictable

3. Who is going to do the work of porting hundreds of interesting (to who?) applications to "your OS" (which OS is that?).

Ported by the author of the OS, the list of applications is also compiled by the author crawling through the github. Or you can offer your own application

Can you provide a link to the film? I saw a TV series "Free Rein" which didn't seem relevant.

https://www.youtube.com/watch?v=M-hogZ5Dz3E

[kerravon]

1. What's wrong with just joining Linux?

Not interested in developing drivers endlessly

Sorry, I don't understand this. With PDOS I don't have drivers, because I am using the BIOS and the need for drivers never arose. So I don't really know what a driver is, because I normally only understand things when I do them. I did write interrupt-driven serial port routines for MSDOS, but they weren't integrated into MSDOS via the official driver mechanism. However, I do "know" that most OSes have drivers, so what's wrong with Linux's use of drivers?

Regardless, what's wrong with Linux as-is? If you don't like developing drivers, then just stop developing drivers. It's a complete working system, and will presumably keep running, even if no more drivers are written. In fact, you can probably start stripping drivers from it.

And if there was a new OS written - what makes you think it won't require the same number of drivers that Linux has?

2. Are you trying to achieve something out of this? Or is it just to have a social club?

It's just an idea, the result is not predictable

Ok, I'm all aboard the "testing ideas" bandwagon, as I don't like seeing unpredictable things.

3. Who is going to do the work of porting hundreds of interesting (to who?) applications to "your OS" (which OS is that?).

Ported by the author of the OS, the list of applications is also compiled by the author crawling through the github. Or you can offer your own application

And if the OS author goes to this enormous effort - what then? I assume no market research will have been done to find out if anyone wants any of those 100 applications and is willing to switch to an unknown OS in order to run them.

Can you provide a link to the film? I saw a TV series "Free Rein" which didn't seem relevant.

https://www.youtube.com/watch?v=M-hogZ5Dz3E

Ok, I have watched the 2 hour movie. The group of people were just unemployed people. Not people with special skills. I think most people developing OSes here understand that no-one is actually going to use them - probably not even themselves. And this forum probably already counts as a "society" comprised of OS developers developing OSes for probably not a lot of purpose. This (apparently) existing society has not been able to unite on an OS, and even if they could be united, I still don't see what we could possibly come up with - even if we all devoted out entire lives to it - for the rest of our lives - that would reach the level of Linux.

Nor is anyone likely to do any market research to try to find some niche. I would have thought that was the first port of call actually - market research.

If the goal is to have one larger OS that no-one uses instead of 20 smaller OSes that no-one uses, that MAY be possible to achieve. But seemingly equally pointless. Especially when you have a really large OS already in existence called Linux.

Note that I'm not dismissing anything you said - and I'm not saying I'm right about anything - I'm mainly just asking questions. Looking for a coherent goal, I guess.

[Alexey1994]

1. What's wrong with just joining Linux?

Not interested in developing drivers endlessly

Sorry, I don't understand this. With PDOS I don't have drivers, because I am using the BIOS and the need for drivers never arose. So I don't really know what a driver is, because I normally only understand things when I do them. I did write interrupt-driven serial port routines for MSDOS, but they weren't integrated into MSDOS via the official driver mechanism. However, I do "know" that most OSes have drivers, so what's wrong with Linux's use of drivers?

Regardless, what's wrong with Linux as-is? If you don't like developing drivers, then just stop developing drivers. It's a complete working system, and will presumably keep running, even if no more drivers are written. In fact, you can probably start stripping drivers from it.

And if there was a new OS written - what makes you think it won't require the same number of drivers that Linux has?

2. Are you trying to achieve something out of this? Or is it just to have a social club?

It's just an idea, the result is not predictable

Ok, I'm all aboard the "testing ideas" bandwagon, as I don't like seeing unpredictable things.

3. Who is going to do the work of porting hundreds of interesting (to who?) applications to "your OS" (which OS is that?).

Ported by the author of the OS, the list of applications is also compiled by the author crawling through the github. Or you can offer your own application

And if the OS author goes to this enormous effort - what then? I assume no market research will have been done to find out if anyone wants any of those 100 applications and is willing to switch to an unknown OS in order to run them.

Can you provide a link to the film? I saw a TV series "Free Rein" which didn't seem relevant.

https://www.youtube.com/watch?v=M-hogZ5Dz3E

Ok, I have watched the 2 hour movie. The group of people were just unemployed people. Not people with special skills. I think most people developing OSes here understand that no-one is actually going to use them - probably not even themselves. And this forum probably already counts as a "society" comprised of OS developers developing OSes for probably not a lot of purpose. This (apparently) existing society has not been able to unite on an OS, and even if they could be united, I still don't see what we could possibly come up with - even if we all devoted out entire lives to it - for the rest of our lives - that would reach the level of Linux.

Nor is anyone likely to do any market research to try to find some niche. I would have thought that was the first port of call actually - market research.

If the goal is to have one larger OS that no-one uses instead of 20 smaller OSes that no-one uses, that MAY be possible to achieve. But seemingly equally pointless. Especially when you have a really large OS already in existence called Linux.

Note that I'm not dismissing anything you said - and I'm not saying I'm right about anything - I'm mainly just asking questions. Looking for a coherent goal, I guess.

Can you provide a list of applications ported/written for PDOS? Or is this list compiled from applications written for MS-DOS, some Windows, some POSIX, but not for PDOS?

I insist that there should be a list of the 100 most necessary, useful, unique applications. For example, I would prefer an application that plows a field using a tractor, a robot arm and a camera. It has nothing to do with the market, I just need it. Leave the market alone, or is everything you do for money? There is no such application on Linux, and on any other system too, but there are thousands of knick-knacks like games, calculators, paints, writers. But there are not even hundreds of really useful/interesting programs. One person should make a decision about usefulness / interestingness, taking into account the opinion of society, but not statistics.

Based on these considerations, I conclude that the OS developer must make a choice which applications he should allow to work in his OS.

For Windows you will have one list, for Linux another, for PDOS a fourth, for BelOS a fifth. And the user of the system will always know why he install it.

[eekee]

Conclusion: you need to form a society of those who are much less socialized than you and become their leader.

Oh, try to boss me around and you will find... trouble! I'm half-joking. I have real difficulties keeping up with people, and there are other issues.

"people who don't know that certain behaviors are inappropriate in a social setting"

Ew! I don't like that definition of autism either. It's more applicable to Asperger's syndrome because people with Asperger's syndrome can learn appropriate social behaviour, but Asperger's syndrome is no longer counted as part of the autistic spectrum. Some people with some varieties of higher-functioning autism can can learn appropriate social behaviour too, but certainly not all.

On a more interesting note...

With PDOS I don't have drivers, because I am using the BIOS and the need for drivers never arose. So I don't really know what a driver is, because I normally only understand things when I do them. I did write interrupt-driven serial port routines for MSDOS, but they weren't integrated into MSDOS via the official driver mechanism.

I thought about using the BIOS to save driver writing, but I didn't because disk access is synchronous. How do you deal with that?

[Alexey1994]

I thought about using the BIOS to save driver writing, but I didn't because disk access is synchronous. How do you deal with that?

This call is very fast on an SSD and is guaranteed to return either a success or an error.

[kerravon]

I thought about using the BIOS to save driver writing, but I didn't because disk access is synchronous. How do you deal with that?

PDOS is single-tasking. It is meant to be a basic starter system so that you can use it to write the "perfect OS" with multitasking etc. It took me nearly 30 years (not full time) just to get that basic system.

[kerravon]

Can you provide a list of applications ported/written for PDOS?

It is in the readme4.txt

pdar386 - archiver for a.out
pdas - assembler for a.out and COFF
pdld386 - linker for a.out
sccwin - SubC C compiler to produce 80386 code
pdmake - build program
pdcc - C preprocessor
portinit - initialize a COM port
portread - read data from COM port
portwrit - write data to a COM port
terminal - a comms program
zap - change bytes in a file
zfill - create a file filled with NUL characters
hexdump - display a file in hex
md5 - find an MD5 signature for a file (non-standard for some reason)
rm - remove a file
mvsunzip - unzip an uncompressed zip file with no directories
sccdos - SubC C compiler to produce 8086 code
s86 - an 8086 assembler
sar - an 8086 archiver
sld - an 8086 linker
devil - communicate with a Wazoo BBS
pdpbbs - a Wazoo BBS
tobruk - a mailprocessor
msged - a message reader
msged15 - msged in 80 * 15 mode
bincount - count in binary
grep - search text files for strings
zcalc - a calculator
xychop - chop up a file
hex2dec - convert hex to decimal
dec2hex - convert decimal to hex
showpic - show a picture
bmp2txt - convert a BMP into a text file
motion - display a picture and make it move
fninit - initialize floating point
sys - install OS
instmbr - install an MBR
bin2hex - convert a binary file into C hex constant string
boot - boot a disk
sectread - read a sector of a disk
sectwrit - write a sector to a disk
sectest - test sectors
parted - create a partition
mkdosfs - make a DOS filesystem
mcopy - copy onto a DOS filesystem
mls - list files in a directory of a DOS filesystem
mmd - make a directory in a DOS filesystem
xcopy - copy lots of files
graphtst - test graphics
mspop - play a WAV file (doesn't work?)
makecd - make an ISO CD image
deltree - delete an entire directory tree
zip - a minimal zip with no compression
as86 - an 8086 assembler
ld86 - an 8086 linker
clnblank - clean trailing blanks in files
ebc2loc - convert EBCDIC file to local character set
mfterm - EBCDIC ANSI terminal, including IPL capability, for mainframes


That last one will be on the next distribution.

I see that I have 156 C files in ozpd. Some are functions rather
than programs. Most are C90-compliant. I could build Windows
executables for the C90-compliant utilities, which would then
run on PDOS/386 and get closer to the 100 programs you mentioned.

So far I only compile things when a need arises.

Or is this list compiled from applications written for MS-DOS, some Windows, some POSIX, but not for PDOS?

None of my distributions runs POSIX.

PDOS/386 doesn't run MSDOS programs - well - unless you count 32-bit MSDOS which is not compatible with what anyone else would call 32-bit MSDOS.

Theoretically PDOS/386 runs an unknown number of Windows applications, but in practice I doubt there is anything except for the Windows applications that I built, which only ever have a dependency on msvcrt.dll or sometimes kernel32.dll too.

I insist that there should be a list of the 100 most necessary, useful, unique applications.

Surely such a list varies between every individual in the world? Also I still don't see what is wrong with just running those 100 programs under Linux.

For example, I would prefer an application that plows a field using a tractor, a robot arm and a camera. It has nothing to do with the market, I just need it.

Only a small percentage of the population would find such an application useful. So I am having difficulty understanding why it would be on your list of 100.

Leave the market alone, or is everything you do for money?

Most things I do are not for money. I do boring work for money like everyone else - not full-time though.

There is no such application on Linux, and on any other system too, but there are thousands of knick-knacks like games, calculators, paints, writers. But there are not even hundreds of really useful/interesting programs. One person should make a decision about usefulness / interestingness, taking into account the opinion of society, but not statistics.

Surely the opinion of society is exactly measured by statistics? And your self-defined problem here is creation of useful apps, not an OS to run them under. There are plenty of OSes that are capable of running the theoretical useful app. The nebulous goal we are discussing is replacing 20 small unused OSes created by individuals here with one larger unused OS, when a huge, used, OS, Linux, already exists. Let's set aside the social problem of getting 20 people here to follow 1 person in the first place, and let him make the decision about - not the OS (for some reason), but useful apps.

Based on these considerations, I conclude that the OS developer must make a choice which applications he should allow to work in his OS.

That's an odd sentence. OSes are normally general purpose. All apps are "allowed" to work. But the app will need to conform to some arbitrary API. To me, that arbitrary API has always been "C90". If anything other than C90 works, that's a bonus, but not to be expected.

For Windows you will have one list, for Linux another, for PDOS a fourth, for BelOS a fifth. And the user of the system will always know why he install it.

In my opinion, we should largely aim for C90-compliant programs built as 32-bit Windows executables that are dependent on only msvcrt.dll.

Then those executables can run under Windows, Linux Wine, PDOS/386, Freedos+HX, ReactOS.

And with simple recompilation, those programs run on many other environments, even the mainframe, such as z/OS and z/PDOS.

Very recently, like days ago, I managed to complete the task of getting the mainframe to drive an EBCDIC ANSI terminal so that you can run micro-emacs or other fullscreen applications that exceed the C90 standard but still conform to ANSI X3.64.

So now there are two standards that interest me.

I'm not aware of a standard for graphics, and I'm not sure if it is possible to bump the mainframe up to support such a standard when even ANSI X3.64 took half a century.

And the graphics would produce an additional dependency on hardware.

Again - I'm not dismissing anything you are saying, I'm just asking questions/clarifying.

[eekee]

I thought about using the BIOS to save driver writing, but I didn't because disk access is synchronous. How do you deal with that?

PDOS is single-tasking. It is meant to be a basic starter system so that you can use it to write the "perfect OS" with multitasking etc. It took me nearly 30 years (not full time) just to get that basic system.

Oh I got'cha. It reminds me that disk caching was optional in the later versions of MS-DOS, handled by a driver you could choose to install if you wanted. The driver was written by Microsoft, but could just as easily have been supplied by a 3rd party. Does PDOS support 3rd-party add-ons for filesystems and other core functionality? Though perhaps my question is void. If it's open source, it may not need explicit support.

[Alexey1994]

Oh I got'cha. It reminds me that disk caching was optional in the later versions of MS-DOS, handled by a driver you could choose to install if you wanted. The driver was written by Microsoft, but could just as easily have been supplied by a 3rd party. Does PDOS support 3rd-party add-ons for filesystems and other core functionality? Though perhaps my question is void. If it's open source, it may not need explicit support.

BelOS supports any changes of the base components)

And in PDOS, I did not understand how to exit from the console program that reads from stdin in the shell. You enter the grep command and that's all, only a restart will help. Of course, I corrected this behavior in my OS.

[kerravon]

I thought about using the BIOS to save driver writing, but I didn't because disk access is synchronous. How do you deal with that?

PDOS is single-tasking. It is meant to be a basic starter system so that you can use it to write the "perfect OS" with multitasking etc. It took me nearly 30 years (not full time) just to get that basic system.

Oh I got'cha. It reminds me that disk caching was optional in the later versions of MS-DOS, handled by a driver you could choose to install if you wanted. The driver was written by Microsoft, but could just as easily have been supplied by a 3rd party. Does PDOS support 3rd-party add-ons for filesystems and other core functionality? Though perhaps my question is void. If it's open source, it may not need explicit support.

No consideration has been made for 3rd party functionality. No-one has requested that either. It's not something that is on my radar at all. I'm not sure I'm the best person to design such a thing either, as I have no knowledge of it. There are some things I am comfortable about designing (e.g. how to deal with RECFM=F/V/U, regardless of what IBM chose), but when it comes to code layout/design, complex algorithms, I'm not claiming to be good at. It took me many years between getting FAT reading working and getting FAT writing working. And even then, it was only FAT-16 I managed to get working. FAT-12 required Alica to come along, and she also added FAT-32 reading and writing.

[kerravon]

Oh I got'cha. It reminds me that disk caching was optional in the later versions of MS-DOS, handled by a driver you could choose to install if you wanted. The driver was written by Microsoft, but could just as easily have been supplied by a 3rd party. Does PDOS support 3rd-party add-ons for filesystems and other core functionality? Though perhaps my question is void. If it's open source, it may not need explicit support.

BelOS supports any changes of the base components)

And in PDOS, I did not understand how to exit from the console program that reads from stdin in the shell. You enter the grep command and that's all, only a restart will help. Of course, I corrected this behavior in my OS.

I don't have an EOF for stdin yet. Nor do I have redirection or piping. grep can still be used on files though. Not sure why you would need grep to work on stdin when piping doesn't exist. Note that the exact same grep.exe will work on Windows too, which supports those things.

[Alexey1994]

I don't have an EOF for stdin yet. Nor do I have redirection or piping. grep can still be used on files though. Not sure why you would need grep to work on stdin when piping doesn't exist. Note that the exact same grep.exe will work on Windows too, which supports those things.

Of course, I paid attention to it, there is a dependency on msvcrt.dll, but in the Windows console it is possible to press ctrl+c and stop the looped process.

I added this to myself in a few lines of code https://github.com/Alexey1994/BelOS/blo ... nput.c#L19

Neither you nor I can add piping to another program, because the systems are single-task. But if you dynamically calculate the relative address through the EIP register, then it will be possible to launch several processes, and one process will switch another through this same piping, that's when it becomes possible.

[kerravon]

I don't have an EOF for stdin yet. Nor do I have redirection or piping. grep can still be used on files though. Not sure why you would need grep to work on stdin when piping doesn't exist. Note that the exact same grep.exe will work on Windows too, which supports those things.

Of course, I paid attention to it, there is a dependency on msvcrt.dll, but in the Windows console it is possible to press ctrl+c and stop the looped process.

Sure, I don't support ctrl-c either. It does work in micro-emacs though - ctrl-x, ctrl-c exits. ctrl-c isn't special. I haven't looked into how best to handle error conditions like that, and I'm not sure I want to either, as it might detract from the simplicity of PDOS.

I added this to myself in a few lines of code https://github.com/Alexey1994/BelOS/blo ... nput.c#L19

The shell? I didn't think that would be involved.

Neither you nor I can add piping to another program, because the systems are single-task.

Note that I think multi-tasking code is present - added by someone else - but I haven't tested it, and it makes the system run hot, so I spent a lot of effort conditionally disabling that code, since the other person is no longer around to maintain it.

But if you dynamically calculate the relative address through the EIP register, then it will be possible to launch several processes, and one process will switch another through this same piping, that's when it becomes possible.

I don't understand this. Can you elaborate?

[eekee]

BelOS supports any changes of the base components

Cool.

No consideration has been made for 3rd party functionality.

I guess that's all right as it's open source; people can add their own hooks or just replace code.

Neither you nor I can add piping to another program, because the systems are single-task.

I wonder how MS-DOS does it, or rather, how FreeDOS has implemented it. *search...* Ah, it's very simple: The shell converts pipes into redirections to temporary files.

Code: Select all

cmd1 | cmd2 | cmd3

becomes:

Code: Select all

cmd1 >%TEMP%\cmd###1.tmp
cmd2 <%TEMP%\cmd###1.tmp >%TEMP%\cmd###2.tmp
cmd3 <%TEMP%\cmd###2.tmp

where % delimits environment variable names.

Slightly more detail in the FreeDOS wiki; search for pipe . On the to-do list are some items which suggest to me it might eventually use memory allocations instead of files. That ties together the two topics of this post, because how would a DOS shell redirect program output to memory? By temporarily replacing the software interrupt vectors for output.