Subj : Re: Large Files To : borland.public.cpp.borlandcpp From : "Ed Mulroy [TeamB]" Date : Sat Sep 13 2003 10:08 pm > Thanks for your quick response. Below are the versions that > I have available. The version of the command line compiler does not tell me what release version you are working with. Do you have Borland C++ 5.0, Borland C++ 5.01 or Borland C++ 5.02? I do not see any issue with spaces in command line arguments. The need to encase such arguments in quotes was introduced around 1987 with Turbo C 1.5, years before Borland C++ was a gleam in Borland's eye. As you can see from the screen capture below such arguments work with the system command. ------------------ C:\Lookat\temp >ver Microsoft Windows XP [Version 5.1.2600] C:\Lookat\temp >type temp60.c #include #include int main(int argc, char *argv[]) { int i; char buf[132]; for (i = 1; i < argc; ++i) { sprintf(buf, "temp61 \"%s\"", argv[i]); printf("system(%s)\n", buf); system(buf); } return 0; } C:\Lookat\temp >type temp61.c #include int main(int argc, char *argv[]) { int i; for (i = 1; i < argc; ++i) printf("argv[%d] \"%s\"\n", i, argv[i]); return 0; } C:\Lookat\temp >bcc32 -WCR temp60.c Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland TEMP60.C: Turbo Incremental Link 5.64 Copyright (c) 1997-2002 Borland C:\Lookat\temp >bcc32 -WCR temp61.c Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland TEMP61.C: Turbo Incremental Link 5.64 Copyright (c) 1997-2002 Borland C:\Lookat\temp >temp60 "arg one" "arg 2" "3rd arg" system(temp61 "arg one") argv[1] "arg one" system(temp61 "arg 2") argv[1] "arg 2" system(temp61 "3rd arg") argv[1] "3rd arg" C:\Lookat\temp > ------------------ I do not understand how one can have a need to keep code compatible with Unix when Delphi apps are part of the package. Delphi is not compatible with any of the Unix operating systems. However, unlike with the function 'system', Delphi does share the functions CreateProcess, WinExec and ShellExecute, all of which can do the same task as system and all of which will work from within a DLL and both of CreateProcess and WinExec can work in the 'background' as you wish, something that system will not do. If I recall correctly I was the one who dealt with you before when you wanted to do file positioning using 8 byte position values. I told you how to do it then in a program which used FILE* style streams. Why is it not usable today? I do not deny the problems you have had with ReadFile and WriteFile but I have done quite a bit with the Win32 file I/O routines under XP and have not seen those problems. The stream functions (FILE* functions) you speak of buffer I/O so do fewer, larger file operations, the exact thing you say fixed your ReadFile/WriteFile problem. An enhancement of the DOS file system is what is used under Win95. NT, Win 2000 and XP use a Win32 file system with many changes. DOS, Win 95 and Win 98* are already obsolete and Windows ME, a product whose workings cause many, myself included, to consider a change to Win 98 an upgrade, will be obsolete in December. If you targeted Win 2000 and Win XP that would probably be a "good thing". http://www.microsoft.com/windows/lifecycle.mspx .. Ed > Trandog wrote in message > news:3f636e92$1@newsgroups.borland.com... > > Thanks for your quick response. Below are the versions that I have available. > > From my standard: (bcc32) > Borland C++ 5.3 for Win32 Copyright (c) 1993, 1998 Borland International > From the free download (bcc32) > Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland > From CBuilder: the about box states: > Professional 3.0 (Build 3.70) > > I began using Borland C in the early 1990's and migrated through several > versions (3,4,5) until Borland became Inprise. I then fought with my collegues > to keep Borland instead of switching to Microsoft. Each new version caused me > problems in converting my processes. Several years ago, Borland staff told me > that there were no changes in the C compiler, and it was probably not worth my > effort to update. But, now, I see that I probably have to. I really do not > want to go through the hassle, but I guess that is life. > > Recent changes have now caused me to deal with new platform issues as stated > below. The largest headache is the large file sizes. You recommended before > that I look at different processes, and I switched to the Windows API's for I/O. > I had used stream opeations in the past in order to keep my code compatible > with Unix, but that is probably not as important at this date. A collegue and I > have developed commpatible dll's that we use interchangably: he writes in > Delphi, and I write in C. It works very well, and I didn't want to rock the > boat by doing any switching. > > The system problem I mentioned is that the command: > "c:\Program Files\myprog.exe" "Arg 1" "arg 2" will not work as the string in > system() under XP, but will under Win9x. For Win XP, NT, 2K, the command has to > be: ""c:\Program Files\muprog.exe" "Arg 1" "arg 2"", but that does not work > in Win9x. I have to check the platform before I call system(). We have decided > against using CreateProcess for certain reasons. The system I write has to run > in both Windows and command line as a series of dll's invoked by either command > line, batch processes, or Windows launchers, (most of the time in the > background) so CreateProcess is not really a viable solution. > > My 5.3 C compiler works fine with the Win API calls for large files with several > exceptions: > > If I write a lot of short records with WriteFile, the system hangs. If I buffer > the writes myself, and write larger records, I have no problems. The very same > code with the Win API routines replaced with file stream routines works with no > problems, except when the file sizes get too large. Also, in WinXP, the > ReadFile operations randomly fail. (I beleive it either related to reading very > short records, or file mis-positioning by SetFilePointer.) The .exe works > correctly in Win9x. .