Hi Paul,
> I have try to stubify games program, to redo the COFF loader. > It does not seems to change anything however. You can do that, but as said, you can also load another DPMI provider as TSR or with your app as argument to run the app with another DPMI, without having to re-stubify. You could try HDPMI or maybe HX RT, DOS32A, DOS4G, DPMIONE, CWSDPMI... > I can compile a small program to open a file in writing, write a char, > then close. In 32 bit mode (wcl386) and it works. No matter on which disk you put the file, even with JEMMEX loaded? > I wanted to compile bolitare, so wanted to compile allegro, so wanted to... That will be tedious. Try using more pre-compiled tools and libraries, in particular for DJGPP quite a few of those are available online and you can probably use various DJGPP tools even with OpenWatcom. Such as CMAKE or BASH. > About MCB chain, I saw there is 11 bytes reserved... was thinking I/we could > use it to have a next pointer, making it possible to have a non-contiguous > chain. No need to introduce new fields here. Let me walk you through an example in DOSEMU2, with classic FreeDOS kernel instead of FDPP: According to the MEM /D /P output, MEM itself starts at 37e:0, which is far below the 5800:0 where your problem starts. So I can open DEBUG: https://stanislavs.org/helppc/memory_control_block.html d 37e:0 shows that also in DEBUG, the environment MCB starts there: 4d 9c 03 1c 00 c3 55 8b etc. As Stanislavs explains, this means that the corresponding program has a PSP at 39c:0 and that the environment memory block is 1c0 bytes in size. Now you calculate 37e + 1 + 1c to get the next block start, which is 39b:0 and d 39b:0 shows you this: 5a 9c 03 63 9c 62 0f b9 followed by the string "DEBUG". Also, you can see the PSP of DEBUG at 39c:0 as predicted. Ignore the c3 55 8b. So this block starts with "Z" instead of "M" meaning that it is the last block (below the 640k boundary) and belongs to the same PSP, but has the size 9c630. Ignore the 62 0f b9. Calculate 39b + 1 + 9c63 and you get the current (fake, but no problem here) end of the chain: 9fff:0. Use d 9fff:0 to see that actually the chain does go on: 4d 08 00 00 23 00 00 00 followed by "SC", the special PSP value 8 means that the area is reserved, 0 would mean it is free. Again adding 9fff + 1 + 2300 you reach the first UMB at c300:0 and so on. Now the thing is that you can shrink the main block of DEBUG and insert a new block into the chain: Change size from 9c630 to 54630 and put a new block at 57ff with size 47ff0 as follows: a 39b:3 dw 5463 a 57ff:0 db 'M' dw 8 dw 47ff db 0 dw 0 db 'RESERVE' db 0 q The q leaves DEBUG. Note that the empty lines have to be entered as shown above, because those mark the end of input. As the modifications were done consistently, everything stays working when DEBUG ends and DOS cleans up. Now MEM shows the following: ... 02b7 3,168 (3K) COMMAND program 037e 448 (0K) MEM environment 039b 55,008 (54K) MEM program 110a 290,624 (284K) free 57ff 294,896 (288K) DOS system code As you can see, I have manually reserved all memory between 57ff:0 and 640k to prevent DOS from touching that :-) You could make the block at 57ff:0 only 4 kB instead of 288 kB and add ANOTHER block, marked as FREE (0 instead of 8 as the PSP value) after the sensitive area to let DOS apps use free RAM on both sides of your problem area, but as you can see, the whole process requires some effort and I was being lazy. The more elegant method would have been to write a tool which will compute everything for you and updates the chain of MCB. It could even take the desired location and size of the reserved area as a command line argument :-) Happy experimenting! Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
