Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Howto receive 4GB memory as one chunk, DPMI + Watcom C (Developers)

posted by alexfru(R), USA, 14.02.2019, 10:32

> > If the problem is in the standard library, you should try allocating
> memory
> > directly either via DPMI functions or HIMEM.SYS (possibly, before the
> main
> > .EXE, and then map it via DPMI).
> yes :( (I have no enough expirience for it, now)
> Also... What about SmallerC's dpstub.asm ? (is this mapping available? may
> be more easy way - just switch to SmallerC?)

First of all you should probably forget about editing any files larger than 2GB-1. That's a FAT16 maximum. FAT32 may let you have 4GB-1-long files, but...

... Secondly, in 32-bit compilers (especially old ones or developed for old systems) long and fpos_t likely won't let you handle more than 2GB-1 for file sizes and offsets. malloc() may also fail for larger sizes (due to possible implementation bugs, even if the underlying DPMI host allows it).

Third, I don't know what size limitations are in e.g. CWSDPMI or DOS4GW. There may be some. Btw, NTVDM on Windows Vista (or was it 7?) and up also limits DPMI memory by default to something like 32MB (can be fixed by poking in the registry, AFAIR).

In reality I wouldn't want to deal with anything larger than 1GB in DOS at all.

Fourth, Smaller C isn't particularly good if you want to do lots of processing. It optimizes nearly nothing. And its malloc() is primitive and not suitable for many allocations (very likely much worse than Watcom's or DJGPP's). Smaller C's <string.h> functions (actually, most of the library functions) are also implemented in slow C.

So, yeah, you'll likely need a custom memory manager for your task.

Another thing to point out is that you shouldn't be using primitive algorithms when working with large text files. You definitely don't want to move 1GB of data in memory every time you insert or delete a character in the middle of a 2GB file. may help here (it's a very simple data structure with a simple implementation).

Speaking of algorithms, if you can't allocate most of free RAM as one block due to fragmentation, you may want to represent your text as Then you can use non-contiguous buffers. The rope is more complex than the gap buffer and needs more memory for the meta data.

As for dpstub.asm, if you specify a large value in -maxheap (when linking), you should be able to malloc() that much memory at once unless the DPMI host has some limitation of its own.


Complete thread:

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