On 5/14/2010 2:41 AM, Andrei Popescu wrote:
On Thu,13.May.10, 23:40:51, Merciadri Luca wrote:Note that, under Windows, I remember that acrord32.exe always blocked the file for writing, even if it was only being read by acrord32.exe. Okay, it's Windows. Bad memories.I thought that was a limitation of the OS (Windows). Regards, Andrei
I believe SOP on Windows is to always use a working copy, not the original file. When it is time to exit the application, the working copy is "moved" onto the original. The OS handles the move, and how Windows actually does that is something I'm not familiar with.
Saving a file does not necessarily overwrite the original file. Instead, the changes are written to the working copy. It is a matter of policy, so different programs can act differently. When the file is closed, though, the saved changes are made permanent.
So, this OS "limitation" is a matter of differing philosophies. To get a certification of "Made for Windows", certain practices must be adhered to. A lesser certification "Works with Windows" is also available.
In other words, the behavior of an application is still up to the author of the program, in spite of the monopolistic tendencies of Microsoft. Increasingly, though, programmers must jump through lots of hoops to get the behavior they want.
One common bad behavior of Windows apps is opening a file and never closing it. It remains open until the person editing it closes it in the app. This causes files to remain blocked for the duration and leads to all manner of disasters. It the event of a serious crash, all those open files become casualities. (Which is one reason why the practice of using working copies is so prevalent.)
I find it interesting that Acroread's behavior is different in Linux. The programmers of the Linux version seem to be aware of *nix standard practice. This is a good thing, I think.
MAA