How to get filesize in 2012?

[Bob M]

I wrote some Borland C++ 3.1 programs about 20 years ago. I recently discovered a virtual DOS called "DOSBox 0.74" which allows me to run these programs on a Windows 7 64 bit computer. I have overcome most of the various obstacles that Windows has thrown in the way. Junctions, really long filenames, etc, but I can't find out how to get the size of a file as a float or double. Using findfirst() to fill in an ffblk works ok until the number gets too large. The ff_size field stores the size as a long. It needs to be a float or double. I had initially used int86x calls, but they choked on the long filenames. The dta (disk transfer area) uses a long also.

Has anyone found a solution to this common problem?

[Cubbi]

In 2012, we use boost.filesystem (or std::filesystem if you have the optimistic VC11 preview)

1 2 3 4 5 6

#include <iostream> #include <boost/filesystem.hpp> int main(int, char* av[]) { std::cout << "The size of " << av[0] << " is " << boost::filesystem::file_size(av[0]) << '\n'; }

The size of ./test is 19998

Although it won't help resurrecting programs written before C++ was even a language.

[hanst99]

With non-future C++ without using external libraries:

std::fstream file("filename");
file.seekg(0, std::ios::end);
std::cout << "Length of " << "filename" << ":" << file.tellg();

[Bob M]

hanst99: Thanks for your suggestion. What compiler was that written for?
In Borland C++ 3.1 I got errors regarding the "std::". It said "Type qualifier 'std'
must be a struct or class name."
I found a similar example on page 131 of Borland C++ Builder 3. It compiles OK, but
the size it returns is always -1. I will post again when I get it working right.

Regarding Cibbi's comment about programs written before C++ was even a language,
he is right. The programs were originally writen in TurboC around 1990. The C++ book
has a 1992 Copyright.

One disturbing thing is that in the example in the Builder book, they use an int to
receive the tellg() output. I need at least a float to deal with some 3Gb files I have
on this computer.

How did you insert your code into the message? I don't see instructions on this website.

#include <iostream.h>
#include <fstream.h>

main() {

ifstream infile("c:\cdir0\filelen\file.exe",ios::binary);
infile.seekg(0, ifstream::end);
cout << "Length of " << "filename" << ": " << infile.tellg();
}

[hanst99]

[ code ] [ /code ] - I believe it's in the stickies. And what Cibbi meant that it was before the language was standardized, which didn't happen til 1998.

What I wrote wasn't for a particular compiler, but it should at the very least support C++ 1998, while pretty much all compilers that are still actively maintained have at least some degree of support for the recently released C++11 standard.

May I ask you why on earth you insist on using 20 year old technology?

Oh, and if you have to deal with large files, you will probably have to rely on platform specific API's.

[Moschops]

std indicates the namespace; part of C++ for a decade plus now. If you're not absolutely forced to use a twenty year old compiler, consider updating to one of the many free modern C++ compilers available.

[Bob M]

hanst99 wrote:
May I ask you why on earth you insist on using 20 year old technology?

It is more of a personal history thing. The programs in question were very popular DOS shareware
utilities. I had kind of written them off, since they did not work in Windows, so they were not
touched for almost 10 years. By accident, I recently discovered that there are diehard WordPerfect
users who still use DOS versions of that program. My programs were originally distributed on an
ASP cd, and one was in the book "DOS 6.0 Power Tools". I still find them useful.
STF (Show Two Files) lets you compare 2 text files side by side, highlighting the differences.
SINCE lets you find which files have changed on your computer within a date range. I could have
used that a few weeks ago when I downloaded the manual for a new printer, and could not find
where Windows or Firefox put it.
RDIR shows disk usage in a pie chart to let you know where space is being used up.
I was surprised to see how much junk there is in the Users directory on Windows 7.

[Athar]

There are now alternatives for all of that.
Any decent text editor (e.g. Notepad++) can compare two files, file search is basic Windows Explorer functionality and analyzing disk space usage can be done with tools like WinDirStat or Disk Space Fan.
There's no real point worrying about anything DOS-related even for a second.

[roberts]

Have you considered upgrading to a more modern compiler? Borland doesn't even make BC++ anymore.

Hell, I've found ansi c code from I don't know when that does voluming on 3D geometry and while it worked rock solid and I could probably make it work still since it was all standard c, even I'm trying to upgrade it to C++ of today on a supported compiler (originally wrote it on a zortech compiler).

[modoran]

Windows provides GetFileSize() and GetFileSizeEx() APIs, this shouls work on every compiler, no matter how old it is.

[hanst99]

That's because they only work if you have the WinAPI available in the first place.

[Catfish]

I was surprised to see how much junk there is in the Users directory on Windows 7.

I hear that! Running Windows 7 64-bit, just like you. It's a bit of tradition, coupled with malice, if you ask me, that Windows releases get ever more bloated.

If you need a more modern compiler for DOS, check out DJGPP.
http://www.delorie.com/djgpp/
DJGPP (AFAIK) partially implements POSIX, which should simplify things like checking file length.

By accident, I recently discovered that there are diehard WordPerfect users who still use DOS versions of that program.

Wow, talk about lolyalty.

[Bob M]

Athar wrote:

There are now alternatives for all of that.
Any decent text editor (e.g. Notepad++) can compare two files,
file search is basic Windows Explorer functionality
and analyzing disk space usage can be done with tools like WinDirStat
or Disk Space Fan

Thanks for the suggestions. I will look into them. I just tried what you call
file search, and was unaware that it could search for a range of dates.

[Bob M]

roberts wrote:

Have you considered upgrading to a more modern compiler?
Borland doesn't even make BC++ anymore.

I was wondering if they were still in the business.
Unlikely I will upgrade, though. I was never interested in Windows programming.
When I was programming professionally, everything was assembler. We controlled
huge machine tools at one company, and even larger rolling mills at another.


modoran wrote:

Windows provides GetFileSize() and GetFileSizeEx() APIs,
this shouls work on every compiler, no matter how old it is.

My approach to getting these old programs running properly would be to write
something that looks at the file's header on the disk, then skip to where
the size is stored and extract the float or whatever is used.

I was very surprised that they ran at all, thanks to the virtual DOSBox I obtained
only recently.

[hanst99]

It's not only for the sake of windows programming, it's for the sake of having an actual reliable language standard and a bunch of language features that were added since back then.

[Bob M]

The error in the snippet I put in the 4th message in this thread is that I should
have used \\ instead of \ for the full filename.

This works:
ifstream infile("c:\\cdir0\\FileLen\\file.exe",ios::binary);

This doesn't:
ifstream infile("c:\cdir0\filelen\file.exe",ios::binary);

It is moot, though, as the function returns a long, which cannot handle the 3Gb+ files.

[hanst99]

That's compiler and platform specific, a long could just as easily be 64 bit (theoretically even more, but that's rather rare).

I STILL think that the underlying problem is that applying decades old technology to new problems quite frankly doesn't work, sometimes you just have to go with the times.

[Cubbi]

It is moot, though, as the function returns a long, which cannot handle the 3Gb+ files.

If you're talking about tellg(), it does not return a long in C++. But it is indeed moot because that code cannot be compiled by a C++ compiler anyway (try it, for example, on http://ideone.com ). That ancient Builder is compiling one of the many prehistoric dialects which were all called "C++" until standardization. Follow its documentation if you want to use it, nothing else would be valid.

I have nothing against resurrecting ancient systems: I have a live 1979 K&R C compiler on Unix 7 in a PDP-11 emulator, but you simply can't expect a 1992 program to be able to handle something a 2012 OS throws at it.

[roberts]

I was wondering if they were still in the business.

They're still in business. They just don't make or support BC++ anymore.

Unlikely I will upgrade, though. I was never interested in Windows programming.

There are a lot of other non-windows compilers out there.

WatcomC++, has gone public domain, g++ for linux, and even MS' VC++ can be used to make console apps.

[Bob M]

I thought I should include a screenshot of the program I recently
revived from years of dormancy.
I don't know if this forum allows direct inclusion of .jpgs so here
is a link.
The thing that surprised me is the size of Allusers.
I downloaded WinDirStat on the recommendation of athar
but it does not show this particular "Hog". Guess it needs some tweaking by this user.
Maybe it ignores system files or something.

<edit> That was the case. It works OK now that I told it to "Follow Junction points",
which by default is off </edit>

http://farm8.staticflickr.com/7001/6824852991_9271880975_b.jpg