Page 1 of 1
About some DOS/32a functions d32a_xxx()
Posted: Thu Aug 02, 2012 3:49 am
by liaoo
Dear all,
I have 2 questions about
DOS/32a functions...
Could anybody provide me with the
“exact function descriptions” of below functions which are found in the directory of
<examples> after installing dos32a(dos extender)... Have anyone ever used these functions ?
1. d32a_getfreemem_low()
2. d32a_getfreemem_high()
3. d32a_getfreemem_total()
4. d32a_malloc()
5. d32a_malloc_low()
6. d32a_malloc_high()
7. d32a_free()
8. d32a_free_all()
And what is the difference between d32a_malloc() and malloc() ?
Ex. Watcom provides void *malloc( size_t size ) BUT why d32a_malloc() is introduced ?
Thanks !
Re: About some DOS/32a functions d32a_xxx()
Posted: Thu Aug 02, 2012 5:19 am
by Tosi
The watcom malloc is probably 16 bits and either returns a near pointer or a far pointer.
Judging by the name, the dos32a extender uses either protected mode or unreal mode, or some other mode in which a 32-bit address space can be accessed. Thus, the dos32a malloc might return a flat 32-bit pointer. Of course, I have never used the extender so I don't know and you would be better off using google to find your answers.
Re: About some DOS/32a functions d32a_xxx()
Posted: Thu Aug 02, 2012 7:30 am
by liaoo
My app is written by combining watcom + dos/32a and I found malloc() will return 32-bit pointer if allocating memory successfully...
( the app runs in flat memory mode thus if print the pointer then get the result like "0:3012FE08" )
I did not find the function descriptions for these in dos/32a source BUT just the declarations in .h file...
The reason why I ask is my app often "reset" or "hang" after specific operations. By some observations I guess maybe this is due to memory allocating/de-allocating...
* In my code I allocated memory and de-allocate it frequently and the memory size ranges from 512Byte to 4MB.
Thus I want to know if d32a_malloc() and d32a_free() are more "stable" ? (because I used dos/32a as DOS extender and they belongs to dos/32a library...)
Re: About some DOS/32a functions d32a_xxx()
Posted: Fri Aug 03, 2012 4:54 am
by Tosi
The 32-bit pointer returned by malloc is not a flat pointer.
It is a combined segment:offset. So if "0:3012FE08" got printed, something went wrong, because "3012:FE08" is what should have been printed. This points to 3FF28h in absolute addressing. Learn segment-offset addressing before writing DOS code, it will save you a lot of pain.
Re: About some DOS/32a functions d32a_xxx()
Posted: Fri Aug 03, 2012 10:41 am
by Nable
to Tosi
This topic is not about pure DOS, it's about some 32-bit DOS extender. So, i'm not sure that segment:offset addressing scheme is used here.
Re: About some DOS/32a functions d32a_xxx()
Posted: Mon Aug 06, 2012 12:04 am
by liaoo
It is true that my app runs at flat memory model and I quoted some information about flat memory as below from:
http://www.azillionmonkeys.com/qed/watfaq.shtml
So WATCOM C/C++'s sweet spot model is the FLAT memory model. FLAT memory model is an analogue of TINY model for 32 bit programs. ES and DS are set to the same selector which points at the base of memory and maps all 4GB of address space. CS is a selector that points to all of memory like DS and ES, but has the execution attribute set, meaning that it cannot be written to directly. SS is set to a special stack segment to make stack overflow easier to detect. This set up allows you to, in nearly all situations, ignore segment/selector registers completely. FS and GS are available for applications to use as they see fit and by default are set to 0.
Unless you are dealing with interfacing to external 16 bit resources (such as APIs implemented through interrupts) you never need to deal with 64K segment limits, or strange keywords like FAR, NEAR or MK_FP. Pointers and int's are both 32 bit, and while its not advisable, you can cast between the two and still be portable to most platforms (16 bit x86 environments and 64 bit DEC Alpha environments being the most notable exceptions.)
Besides, someone told me about these functions as below:
Late in the development of DOS/32A there was an attempt to simplify DPMI programming (which required the use of assembly lang.) by creating a wrapper library around commonly used DPMI functions. The library was abandoned when DOS/32A went open-source and the source of d32a lib is now lost. The functions about query the amount of free memory in the DOS area, the extended memory and the total (DOS + extended). The other ones simply allocate memory from either low or high memory pools. Note the difference: DOS memory is visible for both real- and protected mode code, Extended memory cannot be accessed from real mode and is for protected mode use only.
See DOS/32A specific (i.e. non-standard) DPMI functions 0FF90h-0FF9Ah since those are the functions exposed by d32a library:
http://dos32a.narechk.net/manual/html/p ... /0ff90.htm
http://dos32a.narechk.net/manual/html/p ... /0ff91.htm
...
Re: About some DOS/32a functions d32a_xxx()
Posted: Mon Aug 06, 2012 6:16 am
by liaoo
Dear all,
I found the root cause why app hang or reset and it was due to heap trashed by accessing the memory area which was released before !
* I added _heapchk() in some check points to see if Heap is OK nor not to narrow down the root cause !
F.Y.I
Re: About some DOS/32a functions d32a_xxx()
Posted: Fri Aug 10, 2012 12:57 pm
by bubach
Using font colors should be forbidden for theme compatibility.
Re: About some DOS/32a functions d32a_xxx()
Posted: Fri Aug 10, 2012 3:25 pm
by Griwes
bubach wrote:Using font colors should be forbidden for theme compatibility.
It is.