U211344@HNYKUN11.BITNET (Olaf 'Rhialto' Seibert) (11/10/88)
> Taking a linked-in TCP/UDP/IP and turning it into a separate system > service module is certainly possible; that is what we did to PC/TCP > between our 1.1 release (which worked like PC-IP) and our 2.0 release > (where the TCP etc. are in a DOS TSR). However, it is a bunch of work, > even when you are starting with something designed around a built-in > multitasker (like PC-IP). It might be easier if you have a real O/S > handy (in this area, DOS has very little help to offer). > > The level of effort depends on whether Phil has been planning for this > sort of thing in his in-progress version. If not, it could easily take > a man-year or more. > > James VanBokkelen > FTP Software Inc. Of course I have thought about the matter myself, and I think that given a proper message passing system with (at least pseudo-) multitasking it should not be too difficult. If you are stuck with msdos, you might have some work to do. What I personally have in mind is the following. Suppose you have a server program, such as SMTP. In the current (old) version, the server does some initialization, opening a TCP connection. With that connection it specifies some upcalls. Then it returns to the main loop of the program. Most of the work is then done via these upcalls. In the end, when the user of the machine decides to shut down the server, some de-initialization is done. Note that these upcalls are actually a hack that try to do event- driven programming on a system without something like message-passing. Now if you take a system WITH message passing, you could do the following: The server wishes to open a TCP connection. It calls a function such as tcp_open(), given suitable parameters. This function packs the parameters into a message, which is sent to the TCP system. While the server waits for the reply, TCP finds out what action was requested, carries it out, and returns the result to the server. Back to the server (the user program). Having opened the connection, it enters a wait state to wait for events to happen (messages coming in). Data can arrive, data we wanted to be sent can have arrived at the other side, and the server acts appropriately. This is what gets simulated by the upcalls, with the difference that when you use upcalls the actions are, in fact, performed in the wrong context. (Everyone must agree that it is ugly to do things to be done by an SMTP server from the TCP layer). I already have sketched (for myself) how I would implement such a scheme using message passing on the Amiga. (The Amiga is a system in which many system functions are used by sending mesages). It should even be possible to write it in such a way that (with proper care of course) the same sources can be compiled on a PC to the single, huge, monolithic, non multitasking program the way it is now, but used on the Amiga to split different applications into different executables. (but then you have to accept some uglyness in the upcall/event handling conversion). If anyone is intested in seeing my code I could consider emailing it to you. Note, however, that though the idea is 'portable', the actual implementation looks quite Amiga-specific. Freely_Distributable=Greetings(Not_For_Any_Commercial_Purpose)-> Olaf.Seibert; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ Let me tell you that I disclaim anything you care to name +++ --- Olaf Rhialto Seibert the Marvellous --- U211344@hnykun11.bitnet --- 7167 BYTES FREE *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (11/11/88)
It seems entirely feasible to run multiple threads within a single dos program - all you need is a small interrupt driven kernel to do scheduling and i/o. I've heard that some of the Microsoft C library routines are not reentrant though. Has anyone implemented a kernel for something like this?
dave@WUBIOS.WUSTL.EDU (Dave Camp) (11/12/88)
> >It seems entirely feasible to run multiple threads within a single dos program >- all you need is a small interrupt driven kernel to do scheduling and >i/o. I've heard that some of the Microsoft C library routines are not >reentrant though. Has anyone implemented a kernel for something like this? > I have had similiar ideas, but no (approved) time to work on it. It seems possible to implement a Unix kernel inside an MS-Dos environment. It would be necessary to have a (hidden) file on each directory containing the additional (Unix) information for each file in the MS-Dos directory. I think the order a magnitude of this job would justify it as a substitute for MS-Dos instead of a subprogram. The only thing that would be kept would be the file system, so that one could switch back to Dos programs when necessary. I have heard of a Unix environment that can run Dos jobs produced by the Wendin company. I would enjoy trying it out, but I do not think my boss would approve. I have tried the DesqView software, which implements multitasking in the Dos environment. It is not foolproof to use it though, especially regarding Workspace size. Some of the problems may have been fixed in later releases though. It is a great concept, and I may use it if we get a version that has better reliability.
brian@ncrcan.Toronto.NCR.COM (Brian Onn) (11/14/88)
In article <8811102102.AA00584@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >It seems entirely feasible to run multiple threads within a single dos program >- all you need is a small interrupt driven kernel to do scheduling and >i/o. I've heard that some of the Microsoft C library routines are not >reentrant though. Has anyone implemented a kernel for something like this? Yes, I have. It was a satellite interface on an MSDOS machine. The software had to monitor outgoing satellite data, and capture and process incoming satellite data. Logging to the printer, and data re-transmission (ie RS232 repeater) was also implemented. The thing was basically as you described, a multi-threaded DOS program. The scheduler was driven from a table with a maximum of 10 threads allowed. Each thread got a slice of the CPU, taken away via the timer interrupt. There was rudimentary message passing between the threads, and also a limited memory pool (to allocate the message buffers from). The whole thing ran in the "background", to allow an operator to use a word processor at the same time. The files created with the word processor would ultimately be sent up to the satellite. Non re-entrant C libraries? I suppose that any library routines that keep a static variable storage would not be re-entrant. DOS and BIOS re-entrancy is another story. Brian. -- +-------------------+--------------------------------------------------------+ | Brian Onn | UUCP:..!{uunet!mnetor, watmath!utai}!lsuc!ncrcan!brian | | NCR Canada Ltd. | INTERNET: Brian.Onn@Toronto.NCR.COM | +-------------------+--------------------------------------------------------+