«

On Jan 26, 6:56*am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <ihp4nh$5t...@news.eternal-september.org>,
> Eric Sosman *<esos...@ieee-dot-org.invalid> wrote:
>
> >On 1/26/2011 5:30 AM, copx wrote:
>
> >> "Michael Mouse" wrote in message
> >>news:. ..
> >>> DJGPP is for DOS and that may be the problem, running a DOS program
> >>> under NT based Windows.
>
> >> Indeed. DJGPP is a DOS compiler. The current version of Windows (Windows 7)
> >> may execute this or that DOS app, but it probably won't work correctly..
> >> DJGPP is only stable on DOS and to a lesser extend on Windows 9x.
>
> > * * (Shrug.) *Works fine for me on XP.
>
> The implication seems to be that in Vista/Windows7/whatever, they (MS)
> are going to actually remove DOS support. *There are political reasons
> why some people like to push this as an agenda, but I doubt it will ever
> really happen.


Native support for 16 bit apps, both DOS and Win16, has been removed
from all 64 bit versions of Windows (this is true for 64 bit versions
of XP, Vista and Win7, as well as the Server equivalents), but remains
in all 32 bit versions (actually being implemented via an emulator on
non-x86 versions of Windows). The partial/public justification is
that 64-bit mode on x86 drops support for virtual-86 mode, but the
major real reason is that Windows applications can all interact with
each other via messages and other mechanisms, and the need to support
16 bit handles and whatnot introduces excessively burden on the rest
of the system, or requires an excessively complex mapping layer. That
and clearly MS wants to stop dealing with all the Win16 compatibility
issues.

In any event, MS uses their VM technology with Win7 to provide a
canned 32 bit WinXP VM (cleverly called "XP Mode"), where you *can*
run 16 bit apps (as well as 32 bit apps that have compatibility issues
with later versions). Unfortunately not all versions of Win7 are
licensed to use XP Mode (or at least that was true in the past, I've
not looked at the terms for the basic versions lately). On the Server
versions, while MS doesn't supply a neatly packaged XP Mode, they do
provide their VM product, and the licenses typically allow you to run
at least one guest for compatibility purposes (but you're mostly stuck
installing that guest OS yourself).

And you can use DOSBox (obvious URL) to run many DOS applications
(including many games) on Win64 (not to mention many non-x86 and non-
Windows ssytems). Even many programs that have issues under the
native DOS emulation in the 32 bit versions of Windows. And there are
other VM products you can use, of course.

On Jan 25, 4:03*pm, Hans Vlems <hvl...@freenet.de> wrote:
> Problem description: the program modifies files and the filesystem is
> somewhat slow.
> More specifically, two subsequent calls on the rename function for one
> file fail because the filesystem is slowed down for reasons unknown.
> Waiting for one second is sufficient to avoid this effect.

Just to throw one possibility into the mix...

Windows apparently has a feature called "file tunneling", described
for example at http://support.microsoft.com/default...en-us%3B172190
.. This means that if you do things to a file in quick succession the
results are not what you might expect.

I don't know if this is anything to do with what you are suffering,
but since you are getting odd results when you do things to a file in
quick succession, and don't when you don't, it seems worth mentioning.

I'm not at all an expert on it, but maybe other people here are.

On Jan 26, 1:40*pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 1/26/2011 5:30 AM, copx wrote:
>
>
>
> > "Michael Mouse" wrote in message
> >news:.. .
> >> DJGPP is for DOS and that may be the problem, running a DOS program
> >> under NT based Windows.
>
> > Indeed. DJGPP is a DOS compiler. The current version of Windows (Windows 7)
> > may execute this or that DOS app, but it probably won't work correctly.
> > DJGPP is only stable on DOS and to a lesser extend on Windows 9x.
>
> * * *(Shrug.) *Works fine for me on XP. *Then again, I'm not trying
> to rename() the same file forty-leven times in three milliquivers,
> either. *YMMV.
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid

In this case djgpp runs on a 64 bit Windows Server platform. It runs
fine, no issues at all.
All files I needed are there and, as said, sleep() is available.
The program does not touch the contents of the file, it just renames
the file according to a given specification.
Under certain conditions two subsequent calls to rename() for the same
file may happen. It happened once that a stray
copy of the file remained on disk. Both the real and the stray file
had the same content and that content was correct.
I ran the program on Tru64 and VMS (on an ODS-5 disk) and the program
ran without a problem. So I tend to agree with another poster that I
ran into a race problem, and a pretty rare one as well.
Hans

On Wed, 26 Jan 2011 14:18:37 -0800 (PST), Hans Vlems
<> wrote:

Hans

Is there a particular reason to use DJGPP rather than MinGW?

On 27 jan, 02:45, Mickey Mouse <f...@email.com> wrote:
> On Wed, 26 Jan 2011 14:18:37 -0800 (PST), Hans Vlems
>
> <hvl...@freenet.de> wrote:
>
> Hans
>
> Is there a particular reason to use DJGPP rather than MinGW?

No particular reason other than that I wanted a C compiler that runs
from the command line.
minGW has no support for posix, which means (I think) that it doesn't
support unistd.h and I need that.
Furthermore I don't want to design windows programs, the software runs
from the commandline.

The environment is Windows Server and Citrix, so as an ordinary user I
cannot install software that modifies the registry.
Installing DJGPP is as simple as unzipping a file.
Programming wasn't part of the project in the first place. But it
would be nice if we had this functionality so I decided to write a
program for it. Documents are scanned and the pdf file ends up in a
directory. Each file is inspected and when it passes the quality check
it is moved manually to another directory. The target directory
structure consists of > 1000 directories, each with 14 subdirectories
and a file resides in one of these. The rules for moveing a file are
simple but for humans the operation is error prone. Hence the need for
a program.
The filenames follow a standard and the standard specifies uppercase
codes.
The reason for two subsequent renames is that NTFS is not case
sensitive but only preserves case. On a unix system, abc and ABC are
two different files. NTFS creates a file with the name abc or with the
name ABC but not both.
So calling rename("abc","ABC") will work on unix but won't on WIndows
Server.
Hans

On Wed, 26 Jan 2011 23:40:29 -0800 (PST), Hans Vlems
<> wrote:

>On 27 jan, 02:45, Mickey Mouse <f...@email.com> wrote:
>> On Wed, 26 Jan 2011 14:18:37 -0800 (PST), Hans Vlems
>>
>> <hvl...@freenet.de> wrote:
>>
>> Hans
>>
>> Is there a particular reason to use DJGPP rather than MinGW?
>
>No particular reason other than that I wanted a C compiler that runs
>from the command line.

Mingw does that.

>minGW has no support for posix, which means (I think) that it doesn't
>support unistd.h and I need that.

Mingw has unistd.h for compatability purposes but all the file
handling function are in io.h and stdio.h. DJGPP is only partially
POSIX complient, less sop than Windows and Windows is not fully
complient (no sockets and threads).

>Furthermore I don't want to design windows programs, the software runs
>from the commandline.

These are consul programs that are actualy windows programs that use a
text based window. (Like ping, format do and DJGPP programs)

>The environment is Windows Server and Citrix, so as an ordinary user I
>cannot install software that modifies the registry.

Mingw does require that the environment be modified so that PATH
includes the Mingw bin directory. I would thing that a user can change
the users enironment. On searching my registry the only instance of
"Mingw" in the registry is for my user names environment for PATH, if
that is a problem then MSYS will get around that for you.

>Installing DJGPP is as simple as unzipping a file.

Mingw does have an installer that is more like a downloader unzipper
than an installer.

>So calling rename("abc","ABC") will work on unix but won't on WIndows
>Server.

It does on XP and does on Win2K server, the case changes.

#include <stdio.h>
#include <stdlib.h>

int main (void)
{
FILE *f;

f = fopen ("abc", "wt");
fclose(f);
rename("abc","ABC");
return 0;
}

In article <>,
Mickey Mouse <> wrote:
....
>It does on XP and does on Win2K server, the case changes.

Daffy Duck says: That's not the point!

--
One of the best lines I've heard lately:

Obama could cure cancer tomorrow, and the Republicans would be
complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it. We've constructed an economy in which eliminating
cancer would be a horrible disaster. There are many other such examples.)

On 27 jan, 10:49, Mickey Mouse <f...@email.com> wrote:
> On Wed, 26 Jan 2011 23:40:29 -0800 (PST), Hans Vlems
>
> <hvl...@freenet.de> wrote:
> >On 27 jan, 02:45, Mickey Mouse <f...@email.com> wrote:
> >> On Wed, 26 Jan 2011 14:18:37 -0800 (PST), Hans Vlems
>
> >> <hvl...@freenet.de> wrote:
>
> >> Hans
>
> >> Is there a particular reason to use DJGPP rather than MinGW?
>
> >No particular reason other than that I wanted a C compiler that runs
> >from the command line.
>
> Mingw does that.
>
> >minGW has no support for posix, which means (I think) that it doesn't
> >support unistd.h and I need that.
>
> Mingw has unistd.h for compatability purposes but all the file
> handling function are in io.h and stdio.h. *DJGPP is only partially
> POSIX complient, less sop than Windows and Windows is not fully
> complient (no sockets and threads).
>
> >Furthermore I don't want to design windows programs, the software runs
> >from the commandline.
>
> These are consul programs that are actualy windows programs that use a
> text based window. (Like ping, format do and DJGPP programs)
>
> >The environment is Windows Server and Citrix, so as an ordinary user I
> >cannot install software that modifies the registry.
>
> Mingw does require that the environment be modified so that PATH
> includes the Mingw bin directory. I would thing that a user can change
> the users enironment. *On searching my registry the only instance of
> "Mingw" in the registry is for my user names environment for PATH, if
> that is a problem then MSYS will get around that for you.
>
> >Installing DJGPP is as simple as unzipping a file.
>
> Mingw does have an installer that is more like a downloader unzipper
> than an installer.
>
> >So calling rename("abc","ABC") will work on unix but won't on WIndows
> >Server.
>
> It does on XP and does on Win2K server, the case changes.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main (void)
> {
> * FILE *f;
>
> * f = fopen ("abc", "wt");
> * fclose(f);
> * rename("abc","ABC");
> * return 0;
>
>
>
> }- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

When I started on this program all we needed was very basic
functionality and version 1.0
was less than 100 lines of code. So any gcc compiler was fine, as long
as it was useful without
installing it in the registry (no access, this lives outside ICT
scope).
Four weeks later I sit on >3000 lines of code... And I find DJGPP very
reliable indeed. No worries.

The fact that it works on XP et al, well that's Windows I guess.
Pretty stable these days but sometimes unpredictable.
As said, on Tru64 the program runs just fine without the cumbersome
second rename().
Which is a kludge in my opinion, no need to convince me there.
Given the difference in behaviour among the various Windows platforms
and the fact that
the problem with the stray copy happened just once I feel I can live
with this for a couple
of months. I just ran the program on todays production files and the
"intermediate" filenames show up in the explorer.
I wrote a program that checks whether the files ended up where they
should and no errors, neither do I expect them.

So, yes, minGW might have been a better choice. But DJGPP produces
fine code and I really don't want to change tools.
Thanks for your research on rename, I really appreciated that!
Hans