Le 2013-09-07 16:49, Jim Henderson a écrit :
> On Fri, 06 Sep 2013 17:01:44 -0400, Francois Labreque wrote:
>
>> Why would they need fewer people to support FAT32 by arbitrarily
>> limiting the size of the drives you can use it on to 1/1000th of its
>> full potential?
>
> Because when the code was written, it was written.  To extend the
> limitation requires more code be written.

What do you mean by extend the limitation?  When a programmer was 
assigned the task of writing support for FAT32, why would he (or she) be 
told to only support 1/1000th of the specifications full potential?" 
(Apart from an oops where the programmer checked for a 16 gigabytes 
limit instead of the 16 terabytes supported by the spec)

The 16 GB does not fall on any "natural" limit of the specification. 
Even if the programmer decided to only write support for 512 byte 
sectors, it could still format a drive as big as 2TB.

> To support that extra space in other applications requires testing and QA.

I know that.  I still don't see why this is an issue here.  When the 
programmers were asked to implement the FAT32 system, why would they 
only cripple the implementation? No sane manager would purposefully ask 
his employees to half ass the job, because he should know that it will 
only lead to more work down the road when his team has to finish the 
work, unless there was a direction from upper management to prevent 
users from using FAT32 and force them into a proprietary format.

I usually refrain from conspiracy theories about Microsoft's decisions, 
but those two are the only two possible reasons here:

1.  Upper management prevented large disks from using the FAT32 
filesystem on purpose.
2.  An incompetent programmer can't differentiate between gigabytes and 
terabytes.

> Have you worked in a software company?

Only for the last 18 years, yes.  (albeit, not in the software division, 
but I interact with developpers on a daily basis)

> Do you know how software development and QA is done?

Yes.  That's why I'm saying it doesn't make sense to say that, when the 
specification says you can 2^32 sectors on the disk, the programmers 
would arbitrarily set an upper limit or 2^26 sectors with 512b sectors 
or 2^22 sectors with 4096b sectors.  It creates a lot more scenarios to 
validate.

>
> Even a /minor/ change to the code (say to make disk space reports not
> turn up negative numbers) requires regression testing to make sure it
> doesn't break anything else.  *Trivial* stuff being fixed, done by large
> software companies, certainly, is not actually a trivial thing.
>

That's why I'm saying it would have made more sense to implement the 
full specification the first time, instead of arbitrarily setting a 
limit way below the actual limit.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message