From:	"John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: What files do I Really need?
Date:	Tue, 09 Jun 1998 18:50:57 -0400
Organization:	Two pounds of chaos and a pinch of salt.
Lines:	60
Message-ID:	<357DBC51.ED5B17F6@cs.com>
References:	<357AB511 DOT B08B7341 AT zetnet DOT co DOT uk> <357AF255 DOT 6EBA4D1D AT cs DOT com> <6lgjt8$78m$3 AT trog DOT dra DOT hmg DOT gb> <357C65F5 DOT 22D9D6E6 AT cs DOT com> <6ljsoq$j2p$1 AT trog DOT dra DOT hmg DOT gb>
NNTP-Posting-Host:	ppp107.cs.net
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Walter Gray wrote:
> 
>  :According to DJGPP FAQ chapter 22.16, you can safely delete all zoneinfo
> 
> Sorry to waste your time on stuff I should have read. How do I get info
> to see the djgppfaq.inf file?  At the moment it doesn't and I am hunting
> through it with the old Borland README program.

Get v2gnu/txi390b.zip, the GNU Info reader.  Its installation is fairly
small; once you have it simply type "info" to read all the DJGPP
documentation that you currently have installed.

There is one problem; a menu item for the FAQ was accidentally omitted
from the 'dir' entry in djdev201.zip.  You can correct it by manually
editing the file info/dir (it's a text file) and adding a menu entry for
'djgppfaq.inf'.  The format should be self-explanatory.  Alternatively,
go to your info directory and type "info -f djgppfaq.inf".

> I am in favour of anything that is super-pared-down. I still use MS
> quick-C and turbo-C version 1.5. As for "helping design", my main
> contribution would be to fetch the pizza and say "more comments".

What you could do is help figure out which files really are absolutely
necessary by trying out various combinations on your system.  Figure out
what you, a novice user, seem to need or not need.

> Actually I did have one idea; I wondered if a pre-processor would
> be possible to convert flat-model source code so it could be compiled
> by an old-fashioned compiler like quick-C. I suppose the opposite
> process would be easier. We see Fortran pre-processors that do very
> complicated stuff, so it might be possible.

The problem isn't that converting would be very difficult in and of
itself (although I can think of many instances where it would be
impractical); the problem is creating the logic to scan a complex source
for every possible instance where a 64K boundary might be crossed or a
protected-mode call made and convert it.  How, for instance, would a
program scan for that in this?

char ** lotsa_allocs( int list_size, int elem_size )
{
    char **list
    int i;
    list = malloc( list_size * sizeof (char *) );
    list[0] = malloc( list_size * elem_size * sizeof(char) );
    for ( i = 1; i < list_size; i++ )
        list[i] = list[0] + i * elem_size * sizeof(char);
    return list;
}

I doubt that would work in real-mode if called with something like x =
lotsa_allocs( 1000, 1000 );.

-- 
---------------------------------------------------------------------
|      John M. Aldrich       | "Autocracy is based on the assumption|
|       aka Fighteer I       | that one man is wiser than a million |
|   mailto:fighteer AT cs DOT com   | men.  Let's play that over again,    |
| http://www.cs.com/fighteer | too.  Who decides?"   - Lazarus Long |
---------------------------------------------------------------------

- Raw text -