Date: Thu, 06 Mar 2008 02:21:06 -0400
From: HECTOR SANTOS
To: BRUCE BOCK
Subject: RE: Error level 5 on wcReports
Newsgroups: win.server.wcreports
Message-ID: <
1204788066.37.1204212241@winserver.com>
References: <
1204212241.37.0@winserver.com>
X-WcMsg-Attr: Rcvd
X-Mailer: Wildcat! Interactive Net Server v7.0.454.5
Lines: 90
On 2008-02-28 10:24 AM, BRUCE BOCK wrote to HECTOR SANTOS:
What would cause a level 5 error in a wcReports file section? My
suspicision is
that wcReports may not be able to handle a file size of 2+ GB.
You have any susgestions. This error only occurs when opening this file area that has a file this large. I have several files areas that do this.
After clicking
okay it closes wcReports.
Brian, you could be right. WINSERVER like most 32 bit applications can only handle 32 bits integer values which naturally translates in Windows to 2 GB.
By naturally, I mean 32 bit = 2 GB with no "unnatural" kludging or fancy
math or other considerations which Windows does offer with special 64 bit "Features."
In theory, if done correctly across parts of the system, when viewing a 32
bit integer in UNSIGNED format, then in theory you can double it to 4GB.
But the natural "word size" in the INTEL 32 bit CPU is positive and
negative integer. So a 32 bit integer is:
-2gb to +2gb
In WINDOWS C/C++ language which is what WINSERVER is written in, it has something called a DOUBLE WORD or DWORD, which uses MATH to shift a
negative number into the positive range. So in Windows, if a file size is
-1 gb, in theory, the DWORD "view" of this negative number would be 3 gb.
But note I said "VIEW" because internally, as far as the 32 bit CPU is
concern it is still a negative number.
For example, everything in Wildcat! is 32 bit, including file size fields
and record pointers. The TFileRecord binary structure has the following snippets:
typedef TFileRecord {
DWORD Status // file position
...
DWORD FileSize
...
What that means is that, again, IN THEORY, if you uploaded or saved a file
that was 3GB, then the Wildcat itself will saw it correctly because is use using DWORD.
However, the problem with using DWORD is that it assumes every piece of
the puzzle is using this DWORD.
In other words, Wildcat! may know it is 3gb, but other applications that
are written in other languages, like VISUAL BASIC which is what WCREPORTS
is written in, does not understand a DWORD value.
So its going to see a -1gb.
Even if VISUAL BASIC had such a concept, again, every piece on the puzzle, storage, copying, all the OCXs, all the DLLs, memory managers, even ZMODEM
file transfers, have to do the same idea of using MATH to view
non-negative numbers as positive.
All this means is that 2B is the practical limit, even if Wildcat! itself
has DWORD considerations.
An application has to be special considerations to handle large files like this.
Wildcat! and wcREPORTS makes no assumption about "limits" other than what Windows naturally allows for 32 bit integer values which is 0 to +2gb for positive numbers.
The solution:
Well, we are hoping that we can just move straight into a 64 bit CPU and OS system and naturally view all this as 64 bit. But that is a daunting
design change in Wildcat given its size and # of applications it has work with.
The other alternative is to deal with large file sizes as the individual
levels where it applies. This will take some drastic changes, but not as
big as a complete 64 bit revamp.
But again, understand what I am saying. Even if we get to that specialized point and you were able to add a 3gb file without a problem, it does not
mean other non-wildcat applications accessing the same data or users will
be able to download the large file successfully .
Hope this let you understand what we are dealing with.
---
HLS
* Origin: Prison Board BBS Mesquite Tx //telnet.RDFIG.NET www. (1:124/5013)