Mail Archives: djgpp/1997/03/18/13:37:14
Thank you for your helpful response. I will follow up on your
suggestions as soon as possible (my PC is at home and I am now
responding from work) and get back to you, hopefully within a day.
> > 1. When I run go32-v2.exe, it tells me that I have
> > DPMI memory available: 27435 Kb
> > DPMI swap space available: 0 Kb
> >
> > That 0 looks suspicious. There is likely a serious problem here.
>
> I don't think this is a problem at all. Is 27MB of memory too few for
> what you need to do with DJGPP? If so, you should review the settings
> of the DPMI memory for the DOS box and set it at larger value (I don't
> know enough about NT to tell you how). Otherwise, what do you care
> about the swap file? It's the responsibility of the DPMI host to
> divide the memory between the physical and swap.
27MB is likely to be far more than I would need for the foreseeable
future. The reason I was concerned is because, allegedly, the
information provided was supposed to tell me the limits of what
is available and therefore suggests that, even if I wanted to,
I could not use more than 27MB because no virtual memory is available.
Inasmuch as I will not be adversely affected.... never mind. :)
> > 2. When I run info (from a DOS shell), it seems to work fine.
> > When I type: info gcc it seems to work fine.
> > But when I type: info groff
> > I get an error message: Bad command or file name.
>
> Groff doesn't come with Info documentation, but with man pages. You
> need to read the file README.djg in the txi390b.zip distribution to
> know how to set up Info so it could read man pages.
I created a file, man.bat, which consists of the line
cat c:\djgpp\info\%1.1
and things do work as advertised.
I still have a problem with one of the other files there,
(I think it was utils). "info utils" would cause the error message noted.
Apparently, there is a .inf file which was created from a .tex file.
I will recheck again tonight.
> > 3. df.exe seems unable to handle my large disk.
> > It tells me that I have 999968 1024-blocks (adds up to 1G)
> > and that I have used 0 of them, when I have 2G disk
> > and I have about 1.3G free.
>
> df uses the library function `statfs' to report disk usage. `statfs'
> uses function 36h of the DOS Int 21h to get that info. I suspect that
> either the NT DOS box doesn't support that function completely, or it
> has problems with large partitions such as yours. Could you please
> write a short test program that calls `statfs' and prints the results,
> test it on your machine and tell here what you see printed? I would
> like to exclude a possible bug in df.exe with handling what `statfs'
> returns. For instance, it would be interesting to see what does df
> print for small disks, like floppies. Thanks.
df.exe works fine on floppies.
I will write a small C program and see what happens.
I assume that statfs under djgpp is analagous to that under Unix,
requiring: #include <sys/vfs.h>
with prototype: int statfs(char *path, struct statfs *buf)
where path is a pointer to a string that contains a value such as "C:/"
and buf is a pointer to the structure that will contain returned values
of interest. The function returns 0 on success, and -1 on failure.
> > 4. groff works pretty well except that I got error messages
> > that inform me of a problem in \djgpp\share\groff\tmac\tmac.ps
> > Lines 52 and 53 of that file refer to files that have long filenames
> > but the system seems not able to find them.
> > When I replace the reference to tmac.pspic with the 8.3 compliant
> > name (on my system, that turned out to be tmac~1.psp)
> > that seemed to bandage the problem.
>
> That's because you unzipped the distribution in a way that munges the
> long filenames by appending such numeric tails. You should use an
> unzip program that truncates the names to 8+3 before handling them to
> NT. InfoZip's UnZip is one such program, and it is free.
I will get that program. In the interim, I will try changing the
names of the files, for example from tmac.pspic to tmac.psp,
and see if that works. I should note that, I believe, the filenames
were left unchanged by my unzipping. That is to say, I believe that
the filename of that file on my system really is tmac.pspic
but that the NT system maintains dual names, one that is long and
one that is 8.3 compliant. I believe this because I have two ls.exe
programs, one that displays the long names and the other that
displays only 8.3 compliant names.
- Raw text -