OSDev.org https://forum.osdev.org/ |
|
unite to make an OS https://forum.osdev.org/viewtopic.php?f=2&t=56560 |
Page 6 of 7 |
Author: | kerravon [ Sat Feb 04, 2023 11:25 pm ] |
Post subject: | Re: unite to make an OS |
Alexey1994 wrote: eekee wrote: 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?). Quote: 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. Quote: 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". |
Author: | Alexey1994 [ Sun Feb 05, 2023 2:38 am ] |
Post subject: | Re: unite to make an OS |
kerravon wrote: 1. What's wrong with just joining Linux? Not interested in developing drivers endlessly kerravon wrote: 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 kerravon wrote: 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 kerravon wrote: 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 |
Author: | kerravon [ Sun Feb 05, 2023 8:34 am ] |
Post subject: | Re: unite to make an OS |
Alexey1994 wrote: kerravon wrote: 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? Quote: kerravon wrote: 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. Quote: kerravon wrote: 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. Quote: kerravon wrote: 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. |
Author: | Alexey1994 [ Sun Feb 05, 2023 2:09 pm ] |
Post subject: | Re: unite to make an OS |
kerravon wrote: Alexey1994 wrote: kerravon wrote: 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? Quote: kerravon wrote: 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. Quote: kerravon wrote: 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. Quote: kerravon wrote: 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. |
Author: | eekee [ Sun Feb 05, 2023 2:28 pm ] |
Post subject: | Re: unite to make an OS |
Alexey1994 wrote: 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. kerravon wrote: "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... kerravon wrote: 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? |
Author: | Alexey1994 [ Sun Feb 05, 2023 2:42 pm ] |
Post subject: | Re: unite to make an OS |
eekee wrote: 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. |
Author: | kerravon [ Sun Feb 05, 2023 3:43 pm ] |
Post subject: | Re: unite to make an OS |
eekee wrote: 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. |
Author: | kerravon [ Sun Feb 05, 2023 4:17 pm ] |
Post subject: | Re: unite to make an OS |
Alexey1994 wrote: 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. Quote: 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. Quote: 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. Quote: 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. Quote: 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. Quote: 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. Quote: 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. Quote: 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. |
Author: | eekee [ Wed Feb 15, 2023 11:51 am ] |
Post subject: | Re: unite to make an OS |
kerravon wrote: eekee wrote: 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. |
Author: | Alexey1994 [ Wed Feb 15, 2023 2:04 pm ] |
Post subject: | Re: unite to make an OS |
eekee wrote: 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. |
Author: | kerravon [ Wed Feb 15, 2023 5:34 pm ] |
Post subject: | Re: unite to make an OS |
eekee wrote: kerravon wrote: eekee wrote: 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. |
Author: | kerravon [ Wed Feb 15, 2023 5:37 pm ] |
Post subject: | Re: unite to make an OS |
Alexey1994 wrote: eekee wrote: 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. |
Author: | Alexey1994 [ Thu Feb 16, 2023 2:09 am ] |
Post subject: | Re: unite to make an OS |
kerravon wrote: 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. |
Author: | kerravon [ Thu Feb 16, 2023 3:32 am ] |
Post subject: | Re: unite to make an OS |
Alexey1994 wrote: kerravon wrote: 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. Quote: 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. Quote: 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. Quote: 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? |
Author: | eekee [ Mon Feb 20, 2023 10:22 am ] |
Post subject: | Re: unite to make an OS |
Alexey1994 wrote: BelOS supports any changes of the base components Cool. kerravon wrote: 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. Alexey1994 wrote: 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: cmd1 | cmd2 | cmd3 becomes: Code: 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. |
Page 6 of 7 | All times are UTC - 6 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |