Xref: news2.mv.net comp.os.msdos.djgpp:3673 From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: dxegen questions/shared libs Date: Thu, 09 May 1996 08:08:57 CDT Organization: Rice University, Houston, Texas Lines: 67 Message-ID: <3191ee69.sandmann@clio.rice.edu> References: <318FD59D DOT 1ADC AT acs DOT ucalgary DOT ca> <4morue$5ai AT mark DOT ucdavis DOT edu> <4movfi$gf8 AT news DOT manawatu DOT gen DOT nz> <4mmrv6$e8h AT groa DOT uct DOT ac DOT za> Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > I think most people think (as I did) that DXE's are the "official" DLL's for > djgpp, that's why no DLL loader writers have come forward yet. No such endorsement - DXEs were written with the 80/20 rule - 80% of the need with 20% of the work. They work for what was needed to get V2 released (EMU387 and potentially graphics drivers). My interest in DOS is essentially gone, so I have stopped doing DOS type development, or I would have written something just to prevent from answering questions about DXEs :-) > You mention in the DXE source that you fixed a few bugs in DJ's DLL code, so > I'm assuming you mean the '94 code. Were the bugs the subtle kind that takes > days to find, or would it be worthwhile for me to spend a couple of hours > debugging that code, so we can have (sortof) full DLL capability in DJGPP 2? > (BTW, I have a copy of the o'Reilly COFF book, so you can be as technical as > you like if you want to explain some aspect of the code in detail). DXEs were based 50% on a graphics device driver prototype which DJ distributed to a very limited group back in the V2 alpha days, and 50% on the '94 DLL code. I could never get EMU387 to work with the '94 DLL code, but when I sat down and put new code together from the new projects, and tried to fix it, it didn't take much more than a couple of hours. I have an unreleased DLL code sent to me for review last summer (right in the middle of fixing my flood destroyed house) and if the author says it's OK, that would be the basis to start on DLLs (it's 90% done). My vision was to write the code, define the entry points into the library, run a processor which created a ?.DLL and a ?.A - and then you would just link to the ?.A which transparently did this all for you. > About the global variable problem, is it enough to pass the DXE init routine > (the one whose address is returned by _dxe_load()) go32_info_block (and then > set it up as a global inside the DXE), or must I look at the source code for > each function I may want to call inside the DXE for info on the globals I > need to pass? You need to look at the source. Then you would need to set up a return structure of routines (not just a single routine) so you could call multiple entries for init, etc. > Also, why does printf() crash when used in DXE's? it is because of the global > var problem, or is it yet another subtlety of MS-DOS? Well, printf does I/O (problem #1) and does a malloc (problem #2). > Sorry for the barrage, but I think DLL's are a rather good idea (having come > from an Amiga background :) and I think that they'd be a great addition to > DJGPP. They have a place, yes. But putting the entire libc in one and "sharing" it does have some minor problems... Our current libc is around 0.5Mb in size. With shared libraries, that means "hello world" would need an extra 0.5Mb at run time (and yet another file) to execute over the current setup. Even if we made the shared library work across nested processes (make/gcc/cc1) you still would not usually break even on memory. So, disk space usage would be less, it would be easier to apply libc bug fixes, but memory usage would go up. The complications have made this a low priority for me to look at, and nothing gets written in DJGPP without a champion for the idea with the time, skills and resources to make it happen. There is nothing technically difficult about supporting shared libraries and/or ELF (or any reason not to do so) - it's just someone needs to volunteer a few weeks of time to make either happen.