Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Re MS-DOS7 bug, Patch done! available soon :=) (Miscellaneous)

posted by Ninho(R) E-mail, 25.11.2009, 00:36

>> As for the memory eaten up by my solution, well it's only 368 bytes (and
>> can be loaded in UMBs, if available, by DEVICEHIGH).

> I understood that. But it still wastes memory.

It does. Minimally.

>> The memory is not needed after driver init is
>> finished - so it /could/ be unlinked from the device driver chain and made
> > available for allocation to DOS programs, by manipulating the MCB chain.

> Why not manipulate MCBs during the installation and allocate the table in
> another memory block (at the top of low memory, or at the top of a UMB)?

There are various complications with your suggestion. Messing with mem allocation is always a pain especially while the system is not set up yet (BTDT). Also we can't count on having UMBs or a memory manager available at the point we are called, so we have to envision putting the small block in conventional memory. But the highest possible location would be just under the Sysinit code and structures, typically around the 500 kilobytes mark, leading to stupidly fragmented conventional mem afterwards. It would subsequently be necessary to have a second program for repairing the memory allocation afterwards (assuming the fragmentation does not cause command.com to choke, as happens too easily).

Frankly my method looks more attractive, is "fire and forget", and if the "wasted" bytes are a problem (which they aren't) it can be repaired later.


> This is very simple for UMB installation because DOS doesn't seem to be
> allocating all UMBs right away. However, DOS likely allocates all low
> memory to your driver if it's loaded there, so you have to resize this MCB
> yourself.

It's more complicated, regular MCB-based memory management functions are not the way a driver's initialisation routine reserves memory. In fact MCBs do not exist officially during this phase, although there is one embryonic MCB underneath the suface. DOS memory allocation functions (48/49/A) aren't supposed to be available and even though they in fact are unoficially present, they will not do what you'd expect. A program such as wrapper.sys has to establish a temporary chain of (fake) MCBs, among other things, in order to satisfy executable programs it is EXEC'ing. Regular driver initialisation does not even want to hear about MCBs.


>> (when my little thing is released for "beta" testing, you are
>> welcome to write one however ;)

> Write it yourself. The solution mentioned by you is simple, you just have to ...

Better left as an exercise to the reader :=)

> Besides, a small environment sure fits in this space.

Sure but, you know, a typical DOS system has lots more space lost than this.

---
Ninho

 

Complete thread:

Back to the forum
Board view  Mix view
15112 Postings in 1359 Threads, 247 registered users, 12 users online (0 registered, 12 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum