Date:	Wed, 1 Jul 1998 17:18:29 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Federico Spinazzi <federico AT SysPr03 DOT disat DOT unimi DOT it>
cc:	Vic <tudor AT cam DOT org>, djgpp AT delorie DOT com
Subject:	Re: NT compat (also Linux)
In-Reply-To:	<Pine.LNX.3.93.980701083512.23695D-100000@SysPr03.disat.unimi.it>
Message-ID:	<Pine.SUN.3.91.980701170944.14005E-100000@is>
MIME-Version:	1.0

On Wed, 1 Jul 1998, Federico Spinazzi wrote:

> 0 - I basically work with C with djdev 2.01, FAT drive, gcc 2.7.2.1, NT
> Workstation 4.0, service pack 3;

This same version works for me on NTFS partition as well.

> 1 - symify often doesn't work: i.e. the stack traceback always being
> converted to nothing;

This can happen if the crash is not in the context of your program.  A 
glance at the traceback would be useful here, in particular the selectors 
(DS, CS, SS, ES, etc.) tell a lot about that.

> 3 - SIGFPE (C) signals cannot be catched (well, I'm not able to catch
> them) by the program but are catched by the OS that calls Dr. Watson ...,

This works for me, at least for simple test cases.

> 4 - often make, gcc, less, and so on crash (spelled right ?) with a
> SIGSEV signal; I've never tried to symify the traceback due to 1;

It would be a good idea at least to post the traceback, even if you 
cannot symify it.

In general, don't try to symify programs that come with the DJGPP binary 
*b.zip distributions, since the symbols there are stripped before 
packaging, and symify won't have any info to work with.

> 5 - profiling is virtually impossible (Eli's FAQs tell there is a patch
> for fixing it, but I've never searched it);

Get a patched libc from the site which was announced here a couple of 
weeks ago.  This problem is fixed there.

> 8 - you often have said that from a windows box DOS programs cannot
> allocate more than 64Mb, right ?.

This is only correct for Windows 3.X and Windows 9X.

> go32-v2 always report 0Kb of swap space; how , for hell, go32-v2 sizes 
> the memory avaiable ?

This is not go32-v2's fault: the NT DPMI server just doesn't bother to 
return meaningful info.  (Or maybe it cannot return meaningful info due 
to the way it manages memory for DOS boxes, I don't know.)

Last, but not least: please in the future report any such problems here, 
don't hold them back until somebody asks.  Some of the phenomena you 
describe might be actual bugs that need to be corrected.  But nobody can 
correct a bug that goes unreported.

- Raw text -