PC BIOS function int 21, 48

[BloodyCactus]

Are you sure? Is that Turbo C specific?

it was specific to the original post which was not built with large memory model, AFAIR. obviously far is not needed in a large memory model as all pointers are then far by default.

 

[kerravon]

it was specific to the original post which was not built with large memory model, AFAIR. obviously far is not needed in a large memory model as all pointers are then far by default.

Ok, I see what happened now.

I interpreted "you need to declare it as a far pointer, regardless of the memory model your using" as "regardless of which memory model you are using - even large - you MUST declare pointers as far and do a far cast in order to convert from an integer type".

Whereas you meant "you can overcome that problem simply by using a far pointer, and that works no matter what memory model you are using - even e.g. small".

 

[Renoise]

Reading some old posts about using this dos int, I found why it is failing in my code.
If you use this int 21,48 function, you can't use any malloc, calloc or any other related function which uses malloc internaly in the code, because most malloc implementations will delete (or not see ) the blocks allocated with this function.

This is interesting as I have been trying to get my own allocation fuction running, was facing similar problem and could not find anything on it. For me it behaved a little differently, the memory got allocated by using function 48h, but then any malloc call would fail. Not delete or not see the allocated block, just return NULL every time. It did work the other way around, use malloc then my function. But it still prevents me from using it, especially as I did not realize fopen, fread... etc. also use malloc internally.
Its a disappointment as I wanted to make my TSR program small but using as little of the libraries as possible, using only the file fuctions, which I dont really feel like rewriting.

 

[kerravon]

This is interesting as I have been trying to get my own allocation fuction running, was facing similar problem and could not find anything on it.

Are you aware that he is no longer claiming that that is the case. It didn't sound right - someone else said it didn't sound right - and testing revealed it wasn't right.

There was a test that looked like a failure, but that was interfering with Turbo C's own malloc so it's not surprising that that didn't work.

For me it behaved a little differently, the memory got allocated by using function 48h, but then any malloc call would fail. Not delete or not see the allocated block, just return NULL every time. It did work the other way around, use malloc then my function. But it still prevents me from using it, especially as I did not realize fopen, fread... etc. also use malloc internally.
Its a disappointment as I wanted to make my TSR program small but using as little of the libraries as possible, using only the file fuctions, which I dont really feel like rewriting.

I don't really understand this goal. You think you can save significant space by statically-linking the FILE I/O routines, but do your own memory management? You can take the FILE I/O routines from PDPCLIB (see pdos.org) if you don't want to rewrite them. And ironically the memory management is basically non-existent in PDPCLIB (for the MSDOS target at least) so you already have that anyway too.

It's public domain so you can do whatever you want - no acknowledgement or anything required. I'm more interested in making sure you can obtain your goal - even if it seems odd. And that goal shouldn't be hampered by lack of access to source code that is too long to write yourself (but you would normally be willing to do that - using a replacement public domain library is the equivalent of that).

 

[Renoise]

I don't really understand this goal. You think you can save significant space by statically-linking the FILE I/O routines, but do your own memory management? You can take the FILE I/O routines from PDPCLIB (see pdos.org) if you don't want to rewrite them. And ironically the memory management is basically non-existent in PDPCLIB (for the MSDOS target at least) so you already have that anyway too.

It's public domain so you can do whatever you want - no acknowledgement or anything required. I'm more interested in making sure you can obtain your goal - even if it seems odd. And that goal shouldn't be hampered by lack of access to source code that is too long to write yourself (but you would normally be willing to do that - using a replacement public domain library is the equivalent of that).

Thank you for the tips. My goal nowadays is mostly to test the water of lower level programming, but only to some extent. Making my own alloc/free functions is a far cry from making a whole file I/O andling library. And yet I still to have as much of the code mine as possible, to see more into what is really going on. I have always been using the common libraries that come with Borland C so am familiar with them and am okay with using them. And my (first ever) TSR is working mostly fine and is not that big (considering its mostly C, I bet it would be much smaller in pure ASM). So I just wanted to try to cut off the alloc.h library by making my own, to see if the size the TSR occupies in memory would be smaller. But its okay as it is.

I was curious about why Borland C behaves that way, when I use the 48h DOS function to make my own alloc. After that malloc looks like my code smells and no longer wants to aloc anything. Being mostly new to that, I guess I may be missing some steps to make malloc friendly again. Especially as I learned here its not only malloc itself, but a number of other standard C functions I am using that might start to fail after my tries with 48h.

 

[kerravon]

I was curious about why Borland C behaves that way, when I use the 48h DOS function to make my own alloc. After that malloc looks like my code smells and no longer wants to aloc anything. Being mostly new to that, I guess I may be missing some steps to make malloc friendly again. Especially as I learned here its not only malloc itself, but a number of other standard C functions I am using that might start to fail after my tries with 48h.

It would be helpful if you showed a small example if it not working.

Perhaps:

1. You didn't use a suitable memory model, like large, to handle the return from MSDOS (or use far pointers as an override or whatever).

2. You named your new function malloc, which clashed with Borland's existing use of that name even for internal use.