Mail Archives: djgpp/1996/07/19/14:31:23
On Wed, 17 Jul 1996, Charles Sandmann wrote:
>
> The only way to make the current sbrk() work right with your toggle scheme
> would be to have the "normal" small limit DS loaded when you call it.
> Your algorithm is a good idea, but we will need to re-write some code to
> implement it fully. ^^^^
>
WILL?? Does that mean my idea will make it into DJGPP? Gee, I never felt
so happy! What will the new variable be called? I strongly recommend
__djgpp_fat_ds! Anyway, I have some further ideas for the next [sub]release
of DJGPP.
GO32's obsolete, right? I assume then that all __go32.. stuff in libc is
just for compatibility with V1. That's why I never #include <go32.h> in
my sources and never use any of __go32.. functions/variables, including
_go32_info_block. I think a user should never be forced to use go32 stuff
anymore, still there are some functions that have no exact equivalents,
like __go32_allocate_iret_wrapper, __go32_dpmi_lock_code etc. I think all
the __go32.. stuff should be replaced with __djgpp.. equivalents and just
wrap them. I also think that the upcoming DJGPP book should never mention
any __go32.. stuff, as it is obsolete. <gosh, will I start any sentence
with something different from 'I think'? :)> Plus, I'd suggest adding a new
header file containing all DJGPP's inner low level variables' declarations
(eg. __djgpp_base_address, __djgpp_dos_sel, __djgpp_ds_alias,
__djgpp_app_DS, __djgpp_fat_ds :) etc.), so that a person wishing to do
something really low-level would only need to include <dpmi.h> and the
header I am talking about, say <djgpp.h>. I can write new utility functions,
like __djgpp_hook_hardware_interrupt(int intno, int (*handler)(), int stksz),
and __djgpp_lock_memory(void *address, int size) etc. to replace the
existing __go32.. ones. You see, I volunteered to write a chapter on hw int
programming in the DJGPP book, so I would feel very comfortable to make the
examples as trivial as possible, having some code/headers added to DJGPP.
Do you think it's worth adding?
Also, I have a question on programming style. Suppose I want to lock a
handler, defined in an external asm file. Which way is more
elegant/understandable?
handler.s:
_handler_start:
....
_handler_end:
install.c:
extern void *handler_start, *handler_end;
region.address = __djgpp_base_address + (int) handler_start;
region.size = (int) handler_end - (int) handler_start;
or the other one:
handler.s:
handler_start:
....
handler_end:
_handler_offset: .long handler_start;
_handler_size: .long handler_end - handler_start;
install.c
extern int handler_offset;
extern int handler_size;
region.address = handler_offset + __djgpp_base_address;
region.size = handler_size;
Which one looks nicer???
oh.. smth else. why did you implement _my_ds etc. as inline functions?
wouldn't something like extern short _my_ds asm ("%ds"); be simplier?
And, again, you need that bloody <go32.h> for that (and for _dos_ds as well).
Yep, I see. Someone could try to use _my_ds in aryth expressions and as
would yell "operands given don't match..." But isn't it wrong to use ds in
expressions anyway? I think the above mentioned <djgpp.h> could have
_ds asm ("%ds") and _cs asm ("%cs") as well.
oooooooffff.. I guess that does it. Aren't you guys tired of writing
my looong postings? Tell me if so. I just want to avoid multiple messages.
Martynas
PS: Damn, just remembered.. People have problems under Win95 because
of the djgpp.lnk extension. It seems that 95 handles .lnk files in some
special manner. I'd suggest renaming it to djgpp.ld (updating specs as
well) in the next release.
PPS: Just kill me if I'm annoying... BUT: DJ, why not compile the original
GNU gxx.c for the next release? The current one appends -lgpp etc. even
when -c is specified, so gcc.exe yells.
- Raw text -