Srav said:
Thanks you very much for u r reply. Sorry for delay.
When i run from the C:\temp and some other folder which has the spaces, Yes
, it working fine. So space is not an issue here. It might be bcz of long
name as error shows that 'it could not find a file in
C:\DOCUME~1\...\setup.exe ".
Can you explain indetail about modulo arithmetic, mean while i would google
it to get more idea on it.
Awhile back, 2GB was the maximum size for a partition. Old games
written in that era figured that the partition could never be larger
than 2GB. So they computed free disk space by subtracting the currently
used disk space from 2GB; however, the computation used the difference
from whatever was the next 2GB boundary minus the used disk space. It
wasn't intentional but their computation didn't account for partitions
that were larger than 2GB so there was overflow in the computations
which effect modulo arithmetic (the overflow bits got tossed since there
wasn't anything to hold them and just the remainder was used).
Say you had a 16GB partition and only 5.8GB was used. You have 10.2GB
left. Yet if the computation is working on 2GB boundaries then it sees
the difference between 6GB and 5.8GB to only find 0.2GB is free.
http://en.wikipedia.org/wiki/Modulo
http://en.wikipedia.org/wiki/Modulo_operation
I don't know what algorithm the games might've actually used. That they
were doing 2GB modulo arithmetic to compute the ceiling to the next 2GB
boundary was an observable behavior, not something derived from knowing
their code (game authors are obviously very jealous of their code and
aren't going around publishing it).
To make an easy example of rollover of an undersized variable, say you
define a 4-bit integer (in this example, an unsigned value so the first
bit is part of the value instead of indicating a positive or negative
value). That means the variable can ran from 0 to 15 (0000 to 1111).
When you add 1 to 15 using this variable, what do you get? Can't be 16
because the integer isn't large enough to hold 5 bits. 15 in hex for 4
digits is 1111. Add 1 to it and it overflows to become 0000. This
overflow or rollover is similar to modulo 16 where the remainder from
15+1 is 0.
By not having enough bits in the integer (or those bits from it that are
used in addressing), values larger than what it can hold result in
giving you the remainder from a similar modulo computation. If the game
or its install program is computing on an effective 2GB modulo then you
could have 11.8GB used space which would give a module 2GB remainder of
just 0.2GB although there was another 20.2 GB left in that 32GB
partition. The overflow for their too-small variable effects modulo
arithmetic with the result that it sees too little free space is left
before the next 2GB boundary.
To get around their modulo effect was to add enough files onto your hard
drive to consume more disk space to move the used disk space past the
next 2GB boundary. So if you had 11.8GB used, you would add 0.3GB in
temp files so you had 12.1GB used space. Now the game would compute
14GB - 12.1GB and think there was 1.9GB of free space (despite there
really is 19.9GB available in the whole 32GB partition). You move the
"used space" pointer past the next higher 2GB boundary so the difference
between it and the then next higher 2GB is even greater than it was
before.
http://en.wikipedia.org/wiki/Fat16
"Final FAT16"
FAT-32 came out later than when a game was released or during its
development (and authors were still coding based on FAT-16). Maximum
partition size of 2GB under FAT-16. The games were coded for what was
common at the time and used computations that worked under those
conditions. FAT-32, NTFS, and far more huge partitions is not what they
planned on during development.
Looks like the real problem in your case was due to either spaces or the
length of the path to the installation program.
