Re: Is acroread blind, or ps2pdf dangerous?
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).
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.