ies,comp.os.os2.programmer.misc   
   13:19:06 GMT)   
   Gecko/20101127 SeaMonkey/2.0.11   
   comp.os.os2.utilities:173 comp.os.os2.programmer.misc:2093   
   From: KO Myung-Hun    
      
   Hi/2.   
      
   Jonathan de Boyne Pollard wrote:   
   >> Anyway, I did not release the 0.9.14 because it has not any   
   >> enhancements for end-users, but just for developers.   
   >>   
   >    
   > Well that's clearly wrong, given that it contains something that will,   
   > you tell us, make programs work for end users in this case.  (-:     
      
   Do you think that end users want to know API changes of FAT32.IFS ?   
   Oh, amazing. ^____^   
   Your end users seem to have very powerful ability. BTW, I call them   
   developers.   
      
   > Do you   
   > have a binary of your not-for-end-users FAT32.IFS so that the end-users   
   > can install it and see whether it fixes the DosSetFilePtr() problem for   
   > them?  I'm expecting it not to, looking at the code changes that you've   
   > made, to be honest.  You don't appear to have touched anything in the   
   > ordinary, standard, "raw" path.  But we'll only find out one way or the   
   > other if some of those end users actually get to test this modification.   
   >    
      
   This is just to proof that you don't know anything about IFS programming.   
      
   As I said before, the cause is 'overflow' of a 32bit size variable. You   
   don't understand ?   
      
   And do you think that I committed the changeset to the public repository   
   without any checking ? Please stop kidding...   
      
   If you read the changeset carefully, you could know that it enabled DASD   
   IO only if the volume size is less than 2GB. Otherwise, any Read/Write   
   request encounters 'Access Denied' until a user change the io mode of   
   FAT32 to sector io one explicitly.   
      
   Finally, of course, I have the binary that you're saying   
   'not-for-end-users FAT32.IFS'.   
      
   I don't understand the reason why you would not believe the changeset of   
   the public repository.   
      
   >> In addition, FAT32.IFS already has a good replacement for DASD IO.   
   >>   
   >    
   > To think that that's a "good replacement" is entirely muddled.  It's   
   > neither good nor a replacement.  We don't *want* filesystem-specific   
   > replacements for a standard OS/2 4.5 mechanism.  We want the   
   > operating-system-supplied mechanism that the 4.5 Toolkit documents to   
   > *work*.  As the 4.5 Toolkit doco says, there's a "new" (for 1999)   
   > mechanism for handily reading volumes without having to care what the   
   > filesystem type is or perform *any* filesystem-specific gyrations.  We   
   > have, the Toolkit doco tells us, "common file system APIs" that provide   
   > us with a "greatly simplified migration path for applications".  (And it   
   > *is* greatly simplified, there's no doubt about it.)  It's entirely   
   > backwards and muddled to work in the direction of "replacing" that with   
   > something that requires undocumented you-have-to-be-in-on-the-secret   
   > filesystem-specific gyrations.  That's not improvement.  That's going   
   > backwards to the situation that existed before.  Where "before" is   
   > "before 1999", moreover.   
   >    
      
   Hmmm... Why should OS/2 v4.5 be the standard ? I hope that FAT32.IFS can   
   be used on Warp4 and Warp3 if possible. In addition, I love the backward   
   compatibility of OS/2. BTW what do you mean by 'new' mechanism ? "L"   
   APIs ? Or just DosOpen()/DosRead()/DosWrite()/DosSetFilePtr()/DosClose()   
   APIs ? DASD access using Dos APIs is a traditional way not new from OS/2   
   v4.5.   
      
   And what do you think about FAT and HPFS ? Do they satisfy your needs ?   
   I can say that they also will not work with Dos APIs on the area over   
   4GB of those partitions.   
      
   I think that you don't understand what is a replacement and is a   
   improvement. Ok. Let's call it the difference of point of view.   
      
   Finally, FAT32.IFS itself is a 16bits driver. So it is useless just to   
   add "L" entry points without fundamental changes of the driver model.   
   However, I know, Lars had a plan to support "L" entry points. But I   
   don't know the result. Frankly, I don't think that FAT32.IFS should   
   support "L" entry points because FAT32 file system itself is a 32bit   
   file system and the current FAT32.IFS implements it enough except   
   support for files whose size is 2GB from 4GB, and for DASD IO to the   
   volumes bigger than 2GB. For the volume bigger than 2GB, the sector io   
   should be set.   
      
   I say once more. If you think the ways of FAT32.IFS are not good, just   
   do not use them.   
      
   I don't want to waste my time to useless debates.   
      
   --    
   KO Myung-Hun   
      
   Using Mozilla SeaMonkey 2.0.11   
   Under OS/2 Warp 4 for Korean with FixPak #15   
   On AMD ThunderBird 1GHz with 512 MB RAM   
      
   Korean OS/2 User Community : http://www.ecomstation.co.kr   
      
      
   --- Internet Rex 2.31   
    * Origin: hanarotelecom (1:261/20.999)