Xref: news2.mv.net comp.os.msdos.djgpp:6170 From: Orbital Newsgroups: comp.os.msdos.djgpp Subject: GO32 stuff Date: Fri, 19 Jul 1996 20:04:39 +0300 Organization: LITNET Lines: 99 Message-ID: References: <31ed5a95 DOT sandmann AT dmccorp DOT com> NNTP-Posting-Host: zveris.pit.ktu.lt Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <31ed5a95.sandmann@dmccorp.com> To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp 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 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. 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 and the header I am talking about, say . 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 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 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.