|
It remembers me a post on usenet, some years ago...
I think the guy was named Linus...
Furor fit laesa saepius patientia
|
|
|
|
|
Nothing wrong with wanting to write an OS. Excellent programming practice.
Remember though that the OS is an interface between bios and the applications. So, the starting point would be the ability to control hardware directly by calling BIOS. In DOS days an MSDOS Bible would give you a list of the calls etc. You could always get yourself an old 2nd hand PC and have a go on that. The reason for wanting the old machine is because a lot of the chips were individual and therefore much easier to work on. These days the hardware is very much integrated, though the addresses of standard hardware is much the same, examining the results from your code is much more difficult.
If you can get hold of a copy of MS C6 or MASM (I think it was version 4 or 5 I used for this kind of thing) you could then write your software on your main PC and download it onto your test machine.
When I developed for PC (usually direct hardware stuff for real time processing. I was mainly electronic design then) in the early 80s I had a folder that had the datasheets of every component, with lots of libraries of code. Unfortunately my briefcase was stolen and I never got the chance to rebuild the folder otherwise I would have let you have copies of key sheets. But these components are still available and well documented. A good place to start, for information, would be with IBM. They used to put out a hardware manual with their PCs which was practically a full circuit.
If you can't get an old PC to use there is another way. Obviously you don'e want to experiment at OS level with the PC you work on now. But you could write an OS within an OS. I used to get my apprentices to write an OS within the DOS environment. That is, It would make use of DOS calls for hardware access but would be the user interface/view in all other respects. The same can still be done within the Windows OS. Although it isn't the full project that you are after, it is a good way to get a 'feel' for it.
Normally I wouldn't want direct emails from lists of this kind, but if you are serious about this project then I am willing to help (on an information/advisory level) so feel free to write to me. Why am I being helpfull? Because you are not satisfied with working on a safe cushion of Windows OS, you want to get inside and know how it all really works. If you can keep this level of interest then your going into the bigtime developement, rather than 'production' stuff most programmers end up doing.
We do it for the joy of seeing the users struggle.
|
|
|
|
|
|
Long, long time ago (when Win 3.11 was a toddler) .. I wrote (in assembly) a graphical O/S as my varsity project.
It included disk, mouse, scanner, VGA and sound drivers and virtual memmory handling... I had the best time ever back then (well, maybe because I was in university so no worries back then mon)
So, with that humble varsity experience as my presentation card and if you allow, I'd LOVVVVE to help you with your project.. I don't have much time but I do have some little.. and lots of ideas and tips I learnt back then.
Given that you're going to re-invent the wheel, I'd suggest you REALLY re-invent it (why bother otherwise?) and take a looooong look and nano-kernels: The O/S is as small as it can be.. and I really mean small and all components (even the memory swapper, file system, etc..) are "mortal" processes (like VMS used to have).
Furthermore.. these "components" have COM-like communication which means that you could be using memory located on ... another PC!
If someone had invented such an O/S (I think NeXT was trying to).. TCP/IP.. sockets and all that crap would've never been necesary! "Amoeba" was on such attempt.
Anyway.. I could go on and on and on.. but I'll stop here with my help offer and a litte suggestion to get started: Read "Operating System Concepts" by A. Silberschatz, J.Peterson and P.Galvin (I think it is used in varsity)
Sonork ID: 0.2
|
|
|
|
|
Hey i also thought about writing my own O/S and have done a bit but got stopped due to other reasons it's great fun. Maybe a load of us should start to write a proper O/S anyway have alook at this site. I found this the best site for O/S stuff and initial ideas.
http://www.nondot.org/sabre/os/articles
Anyway i wish you the best of luck.
|
|
|
|
|
Amigo, This is a mucho excelente site!!!
GREAT RESOURCE!
Sonork ID: 0.2
|
|
|
|
|
You might be interested in Linux kernel module development.
and particularly in HURD.
Chk out the FSF web sites
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
Nish is a BIG fan of Goran Ivanisevic
|
|
|
|
|
Hi, I was thinking just the same thing. Im quite new to C++ but have done assembler and have a good knowlege of the O/S structure. I am a very fast learner and wanted to try to build an O/S to realy strech myself. Have you gained any knowlege yet that could be of help to me? I am just gettin a few ideas at the mo, i am not ready to start this project for anouther month or so as i am just finishing my degree but perhaps then we could exchange problems and ideas?
An Expert is somone who has previously made ALL the Mistakes, I dream of this day. - Lucky
|
|
|
|
|
What does the "c run-time" mean?
|
|
|
|
|
Most languages use a run-time library, that contains implementations of functions that "have to be" in the language.
For C, this is for example the implementaiton of printf, File I/O, memory managment, and all the zillions of functions you can #include <somestdheaderfile.h>
Peter
|
|
|
|
|
Ok, I'm a bit perplexed with simple concept.
I have a small client/server app. I'm sending <1024 bytes of data from the client to the server with the send() function call. On the server, I read this data with the recv() function call. I assumed that this would "consume" the data, and the next call to recv() from either side would block because there is no more data to get. Well, for some reason, the data remains, and I am confused why.
Here are the steps of the program:
1. Client sends file name to Server with send()
2. Server reads file name with recv()
3. Server tries to open file; if successful, send back "yes" else send back "no" using the send() function.
4. Client calls recv() to find out whether open() was successful.
At this point, if I didn't send the "yes" or "no" back to the Client, I thought the call to recv() on the Client would block because there would be no data to read. However, it reads in the data that it originally sent to the Server (i.e., the filename).
Where am I going wrong here?
I realize this isn't the best solution. I have a better one that works, but I tried this first and the mystery has me perplexed. I didn't post the code because it is lengthy.
Thanks,
Jon Sagara
"Oh Lisa, you and your lies. Bart's a vampire, beer kills brain cells. Let's go back to that building... thingy... where our beds... is."
|
|
|
|
|
So now I'm thinking the read() returns 0 when there is no data to read. I think in my case, I was actually reusing a dirty buffer, giving me the bad results.
So read()/recv() will only block if I partially fill the buffer but it is expecting a full buffer. Is this correct?
Jon Sagara
"Oh Lisa, you and your lies. Bart's a vampire, beer kills brain cells. Let's go back to that building... thingy... where our beds... is."
|
|
|
|
|
You can set the socket to be either blocking or nonblocking. recv() should return 0 only when the connection has been closed at the other end. If the socket is set to blocking behaviour, recv() blocks only when there aren't any bytes in the receive buffer.
|
|
|
|
|
How do you specify that?
Jon Sagara
"Oh Lisa, you and your lies. Bart's a vampire, beer kills brain cells. Let's go back to that building... thingy... where our beds... is."
|
|
|
|
|
ULONG mode = 0;
WSAIoctl(m_socket, FIONBIO, (LPVOID) &mode, sizeof(ULONG), NULL, 0, NULL, NULL, NULL);
|
|
|
|
|
I was on Unix, so that wouldn't work, but I was able to make it work another way.
Thanks for the answer, though.
Jon Sagara
"Oh Lisa, you and your lies. Bart's a vampire, beer kills brain cells. Let's go back to that building... thingy... where our beds... is."
|
|
|
|
|
Got it. It was a small misunderstanding on my part.
Jon Sagara
"Oh Lisa, you and your lies. Bart's a vampire, beer kills brain cells. Let's go back to that building... thingy... where our beds... is."
|
|
|
|
|
Hello,
I have an idea from my work that use computer for process something in realtime. But Windows9x or WindowsNT does not support all access to hardware and OS kernel get all time for its works.
Could I use MS-DOS for real time problem?
Or write new own OS simply like MS-DOS. But writing new OS kernel is very difficult. If it is rather than, where does it start? how does it start?
Please help me. Thank you very much!
Nguyen Le Nam
|
|
|
|
|
Realtime processing within MSDOS was always a tricky thing, less so in Windows.
The solution depends on what size of time you need to be within. For example a realtime process that only has to react per minute would be fine in any OS, since the time slice is much less than a minute.
In DOS you are not in timeslices. Your program is called, and that is the only program running until your program ends. Except of cause drivers (TSRs - transient-stay-resident) running on interrupts. So, in this case you would want a driver that triggers a call in your program. A typical one would be on receiving data at a serial port. You would write software to buffer incoming data and trigger a software interrupt which calls a callback function in your main code. This is realtime with loss of driver-time, your programs reaction time and your own process-time (about as real as it gets in DOS). Direct access to the IRQ (interrupt controller) is no longer available in Windows, though it is not so much needed.
In Windows (after Win3.x that is since 3.x was still a DOS machine), 98/NT/2000, you actually have it better since the port stream is for the most part handled for you. You only need to capture it then set a callback. As you are in timeslices your main program can carry on working on its data, then on a call from incoming data you collect and process.
How real the time is depends on how much processing you need to do on the data and the speed of your machine. If the processing is longer than the time between receiving new data then obviously you are not in realtime and have to account for this in the processing itself. Carefull use of threading can increase your programs response time. But the speed of modern machines are generally fast enough to give you 'effective' realtime.
On a worst case instance with Win95, I had to effectively crash Windows. I let my code take all time from the machine in order to keep up with the incoming data. The same project on a proper timeslice OS runs without problem (other than the standard bugs we all write).
We do it for the joy of seeing the users struggle.
|
|
|
|
|
I am trying to write a client app that can monitor IP ports. Like which ports are taken and what are they being used for. I have done some work with WinSock and Win32 networking API, but can't find anything about this. I would prefer a means to set a message if on a single port or multiple ports that fire when the port becomes active, but will settle for a port listener that will check the ports and tell me what is going on with them. Has anyone tried this before?
Thanks.
Leo T. Smith
Senior Programmer/Analyst
Hartwick College
|
|
|
|
|
What operating system?
Norm Almond
Chief Technical Architect
FS Walker Hughes Limited
|
|
|
|
|
The OS is Actually any of the Win32 Platforms. I will use the Win32 API's to detect OS, and the whichever code is necessary (UniCode conversion also is not an issue). I would prefer API calls or direct TCP/IP functions over MFC Wrappers.
Leo T. Smith
Senior Programmer/Analyst
Hartwick College
|
|
|
|
|
Look at the "IP Helper" stuff on MSDN! There's a whole section on it.
Norm Almond
Chief Technical Architect
FS Walker Hughes Limited
|
|
|
|
|
Try look at the open Source project WinDump (for Windows) or TcpDump (for unix). It sniffs all network trafic based on filters! But you have the source and can make your own filters.....
http://www.tcpdump.org/
http://netgroup-serv.polito.it/windump/
Cheers, Frank
|
|
|
|
|
Hello Leo,
There is a very good article by Ton Plooy in the February 1998 edition of the Windows Developers' Journal. The title is : "Scanning Internet Ports". A sample program with full source codes is also given. The following is the link to the article :
http://www.wdj.com/articles/1998/9802/9802b/9802b.htm?topic=articles
I believe the sample program will be perfect for you. Best of luck.
Regards,
Bio.
|
|
|
|