Re: Operating System differences and Ada OS independent programming

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2016-03-22 16:08, G.B. wrote:
> On 22.03.16 14:40, Dmitry A. Kazakov wrote:
>
>>> Would this be real:
>>>
>>> 1. Take a zipped archive, produced by a real ZIP program,
>>>     of an Ada program's file system hierarchy on System A.
>>>
>>> 2. unzip in the same manner on System B.
>>>
>>> 3. Expect Ada's (not yet real) file system related types
>>>     to handle the files thus transported.
>>
>> Sure.
>
> I take it that the certainty refers to "real". OK.

Yes, it is real.

>> Considering that file paths have equivalents in the given file
>> system = an implementation is possible [*]. There would be no problem.
>
> Except that possible /= real yet: Do we get there without
> making ZIP aware of Ada's data representation needs?

Yes. The requirement, again, is that it would be possible to do = ZIP's 
internal representation of paths would allows packing and then unpacking 
file in question.

If it does, there is no problem to create that ZIP's representation from 
Ada's object and conversely create an object from the representation.

It is all about serialization, nothing to do with files.

> Or without making the file system a typed file system,
> for that matter?

The properties of the file system are of no interest, so long the 
equivalent paths exist.

>> And in general, what your concern might be, is unrelated to the problem
>> at hand. You are talking about serializing/deserializing some language
>> object. This problem is independent on what the object is supposed to
>> be.
>
> Alas, mentioning that an object is supposed to be something
> does not say what it should be in any interpretation.

Any interpretation of what?

> Related question: What is a proper description of the "Form"
> parameters of Ada's I/O routines, in terms of a standard Ada
> type, or several standard Ada types?

The proper description of the "Form" parameters is a "hack", "bad 
design". Obviously there should be no such thing. If the user wants some 
system-dependent stuff he is welcome to use system API. Annex 
Interfaces.C is his friend.

>> BTW, you forgot:
>>
>> 4. Pack it again and make sure that the new archive is exactly same.
>
> Isn't the symmetry (modulo time stamps) already a consequence
> of A and B not being specific?

The normalization issue. Under Windows file names are case-insensitive. 
For an implementation to be useful, no symmetry is required. There are 
classes of equivalence of file names under practically *any* OS/file 
system. Therefore no symmetry is possible even in theory.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de