peter@sugar.UUCP (Peter da Silva) (10/26/87)
The "sample DOS device" Matt Dillon posted isn't re-entrant. It's serially reusable, but it won't allow two copies to run concurrently. Is this a problem? I know it would be for a CON: type device, but can you depend on the device being called in a well-behaved manner? That is, it won't be called again until it's been formally removed. How *do* you remove drivers? Is it acceptable to do so? How much of the startup code is related to it being a driver, and how much is related to it being this particular driver? That is, what can I chuck out if I'm going to use it for VT100:? [answer: if you don't know, you ain't gonna be able to get it working anyway :->. right?] I know I can't call dos.library from a driver. How about intuition.library or graphics.library? Apropos of which: Is it worthwhile supporting the clipboard in vt100:? Do any other programs than Notepad actually use the silly thing? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/28/87)
>The "sample DOS device" Matt Dillon posted isn't re-entrant. It's serially >reusable, but it won't allow two copies to run concurrently. > >Is this a problem? No. Only one TEST: can run at a time with the same image. If you notice, I set the Task field in the device node which means DOS will not startup a TEST: for each reference. Multiple Mountlist entries brings in the binary multiple times so there is no problem there. If I were to write a CON like device, I would not set the Task field in the device node and would have to be careful to make it fully reentrant. This means no global variables except SysBase and DOSBase!!! unless they are to be shared (i.e. follow some locking protocol). >How *do* you remove drivers? Is it acceptable to do so? Good question. I think DOS removes cached drivers under low memory conditions. >How much of the startup code is related to it being a driver, and how much >is related to it being this particular driver? That is, what can I chuck out >if I'm going to use it for VT100:? [answer: if you don't know, you ain't >gonna be able to get it working anyway :->. right?] Most of the startup section is generic.... it should be obvious by looking at it. >I know I can't call dos.library from a driver. How about intuition.library >or graphics.library? Sure... this is just another process. You don't want to call something that will go through DOS. That is, your program can pause, but the condition that causes it to continue should not be dependant on dos. (i.e. a Read() call or something). >Is it worthwhile supporting the clipboard in vt100:? Do any other programs >than Notepad actually use the silly thing? The problem with the clipboard is that it is somewhat unneccesary considering that we already have a device oriented DOS... it makes more sense to make the clipboard a DOS device that programs can write to without having to do anything fancy... Have the DOS handle standard conversions to IFF... so you can do things like 'CLIP:IFF' and read or write raw IFF, or something like 'CLIP:TEXT' and write standard text with the driver converting to IFF internally. -Matt
peter@sugar.UUCP (10/31/87)
In article <8710280010.AA05859@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >I know I can't call dos.library from a driver. How about intuition.library > >or graphics.library? > Sure... this is just another process. I thought it was a task, not a process. Speaking of which, could you explain how you're building the process that's handling the debugging code? It's kind of muddy exactly what's going on here. Are you going to write a sample exec device next? (mattdisk.device). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (11/01/87)
>I thought it was a task, not a process. Speaking of which, could you explain >how you're building the process that's handling the debugging code? It's kind >of muddy exactly what's going on here. > >Are you going to write a sample exec device next? (mattdisk.device). Certainly. DOS will create the device driver as a process. Thus, it is a process. If you look at the source for the debugging process, you will note that I make a CreateProc() call. So the debug process is, well, a process also. If I had used CreateTask() it would have been a task. (Side note: Note that you have to face a seglist in CreateProc()). Since the debug process is in the same binary as the device driver, all global variables are shared. The debug process simply uses the device driver's library base variables (SysBase, DOSBase), since they would not be different if the device driver openned the libraries itself. Remember that the link library routines are also shared, but since they simply make run-time library calls this is ok. A separate debug process is needed to prevent confusion on the device driver process's message port. This port is used by the device driver process to handle incomming packets and thus cannot be used as a reply port to outgoing packets (which is what most DOS library calls require). So, we need a separate debug process to make the DOS library calls since it's process-message-port is free. -Matt