Operating System differences and Ada OS independent programming

Operating System differences and Ada OS independent programming

[ldries46]

As Ada is a computer langauge that is by definition OS independent. The 
following question coup:

How to work with filename differences on different platforms, for instance 
creating a program that has to run on Linux and Windows both

For example a file can be in Windows on: ..\..\name  and on Linux on 
../../name
or in windows on C:\directory\* while in Linux on dev1/directory/*

Is there a general form which can be used or is there a routine which can be 
used to determine which operating the program is on. Maybe there is some 
kind of pragma defined which can be used the same way as in C/C++ compiler 
diectives.

L. Dries 

Re: Operating System differences and Ada OS independent programming

[gautier_niouzes]

On Monday, March 21, 2016 at 2:18:08 PM UTC+1, ldries46 wrote:

> For example a file can be in Windows on: ..\..\name  and on Linux on 
> ../../name

Often it is preferable to use relative paths, and many Windows run-times (or perhaps Windows itself) understand "../../name", so you can do much with Unix-like relative paths. For calling an executable in current directory in Unix you need, IIRC, "./myprog"; this command should do the job on Windows as well. And observe the casing in order to have it running on Unix or Linux.
With some trial-and-error you may find a comfortable common denominator.
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address 

Re: Operating System differences and Ada OS independent programming

[Dennis Lee Bieber]

On Mon, 21 Mar 2016 14:18:03 +0100, "ldries46" <bertus.dries@planet.nl>
declaimed the following:

>
>For example a file can be in Windows on: ..\..\name  and on Linux on 
>../../name
>or in windows on C:\directory\* while in Linux on dev1/directory/*
>
	Windows APIs don't care -- feed them / all day. It is only if you are
passing the file name to something that uses a command line interpreter
("shell") where the / becomes an option introducer and you need \.

	
>Is there a general form which can be used or is there a routine which can be 
>used to determine which operating the program is on. Maybe there is some 
>kind of pragma defined which can be used the same way as in C/C++ compiler 
>diectives.
>
	Standard library Directories
http://www.adaic.org/resources/add_content/standards/05rm/html/RM-A-16.html
may provide some help, though it appears to lack a "normalize path"
operation... The compose() operation may allow for building up OS
compatible paths but is nothing like Python's os.path.join()
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Operating System differences and Ada OS independent programming

[Randy Brukardt]

"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message 
news:dta0fbll6sipc98r88nacm4k9adthj3amn@4ax.com...
...
> Standard library Directories
> http://www.adaic.org/resources/add_content/standards/05rm/html/RM-A-16.html
> may provide some help, though it appears to lack a "normalize path"
> operation... The compose() operation may allow for building up OS
> compatible paths but is nothing like Python's os.path.join()

There's also Ada.Directories.Hierarchical_File_Names, which adds some of the 
missing parts. (Unfortunately, GNAT missed its addition to Ada 2012, so it 
might not be much help in practice.)

"normalize path" is an attractive idea, but it's pretty much unimplementable 
on Windows. Certain Windows operations will normalize paths, but they don't 
do it consistently. And with the long and short file names on Windows, paths 
*really* need to be normalized. But various Windows documentation says that 
comparing file names should never, ever be done on a Windows system. (It 
turns out that whether two file names are equal depends on the locale 
setting, on the file system of the partition that contains the file, and 
other variables. So it's impossible to compare paths accurately unless you 
know the file system involved -- which makes a general path comparison 
routine impossible [a general routine has to be able to compare paths of 
files that don't necessarily exist, as that might be a preliminary to 
creating a file].

If one follows the advice to avoid comparisons, then there is not much need 
to normalize paths in the first place.

                                   Randy.

Re: Operating System differences and Ada OS independent programming

[Dmitry A. Kazakov]

On 21/03/2016 23:04, Randy Brukardt wrote:
> "Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
> news:dta0fbll6sipc98r88nacm4k9adthj3amn@4ax.com...
> ....
>> Standard library Directories
>> http://www.adaic.org/resources/add_content/standards/05rm/html/RM-A-16.html
>> may provide some help, though it appears to lack a "normalize path"
>> operation... The compose() operation may allow for building up OS
>> compatible paths but is nothing like Python's os.path.join()
>
> There's also Ada.Directories.Hierarchical_File_Names, which adds some of the
> missing parts. (Unfortunately, GNAT missed its addition to Ada 2012, so it
> might not be much help in practice.)
>
> "normalize path" is an attractive idea, but it's pretty much unimplementable
> on Windows. Certain Windows operations will normalize paths, but they don't
> do it consistently. And with the long and short file names on Windows, paths
> *really* need to be normalized. But various Windows documentation says that
> comparing file names should never, ever be done on a Windows system. (It
> turns out that whether two file names are equal depends on the locale
> setting, on the file system of the partition that contains the file, and
> other variables. So it's impossible to compare paths accurately unless you
> know the file system involved -- which makes a general path comparison
> routine impossible [a general routine has to be able to compare paths of
> files that don't necessarily exist, as that might be a preliminary to
> creating a file].
>
> If one follows the advice to avoid comparisons, then there is not much need
> to normalize paths in the first place.

The need is to have portable programs working with directories. 
Comparisons are necessary to have ordered sets of paths. BTW, path 
comparison has nothing to do with the question if both paths denote the 
same file or the same set of files. Under most OS it would be impossible 
to tell normalized path or not. The very notion of "same file" might be 
meaningless under certain circumstances.

Of course, it is not normalization what is needed, but proper typing 
instead. Path is not a string. It must be a defined in the Ada standard 
type with basic operations including OS-dependent string to path 
conversion and backwards. Of course standard packages must take 
instances of the type as parameters when opening a file. This will 
eliminate most if not all real problems (as opposed to imaginary ones) 
with it.

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

Re: Operating System differences and Ada OS independent programming

[G.B.]

On 22.03.16 09:43, Dmitry A. Kazakov wrote:

> Of course, it is not normalization what is needed, but proper typing
> instead. Path is not a string. It must be a defined in the Ada standard
> type with basic operations including OS-dependent string to path
> conversion and backwards. Of course standard packages must take
> instances of the type as parameters when opening a file. This will
> eliminate most if not all real problems (as opposed to imaginary ones)
> with it.

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.

Re: Operating System differences and Ada OS independent programming

[Dmitry A. Kazakov]

On 22/03/2016 12:15, G.B. wrote:
> On 22.03.16 09:43, Dmitry A. Kazakov wrote:
>
>> Of course, it is not normalization what is needed, but proper typing
>> instead. Path is not a string. It must be a defined in the Ada standard
>> type with basic operations including OS-dependent string to path
>> conversion and backwards. Of course standard packages must take
>> instances of the type as parameters when opening a file. This will
>> eliminate most if not all real problems (as opposed to imaginary ones)
>> with it.
>
> 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. Considering that file paths have equivalents in the given file 
system = an implementation is possible [*]. There would be no problem.

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. After all, a string path, is also nothing but a serialized file 
system entity. The problem is that the choice of how to do this 
serialization was not good enough if the entity should cross file system 
borders.

BTW, you forgot:

4. Pack it again and make sure that the new archive is exactly same.

----------------
* Consider the FILES-11 file system where name is DM:[10,10]TEST.TXT 
with file names limited to 7 characters long and RADIX-50 character set. 
Of course it would be impossible to extract a file with the path of 10 
levels deep there.

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

Re: Operating System differences and Ada OS independent programming

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

On Tue, 22 Mar 2016, Dmitry A. Kazakov wrote:

> BTW, you forgot:
>
> 4. Pack it again and make sure that the new archive is exactly same.

That should be an error. At least, the new archive should have a different 
timestamp / creation time. ;-)

--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: Operating System differences and Ada OS independent programming

[G.B.]

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.

> 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?
Or without making the file system a typed file system,
for that matter?

> 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.

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?


> 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?

Re: Operating System differences and Ada OS independent programming

[Dmitry A. Kazakov]

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

Re: Operating System differences and Ada OS independent programming

[gautier_niouzes]

On Tuesday, March 22, 2016 at 12:15:17 PM UTC+1, G.B. 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.

Dmitry:

> 4. Pack it again and make sure that the new archive is exactly same. 

No problem with all that, as long as you don't use drive letters.
With Zip-Ada it's a piece of cake.
For 4. you can compare two archives with the Comp_Zip tool.
I would add:

5. Use the Zip archive as a portative file system. You can access the archived entries as streams with UnZip.Streams. No need of a real system B there.
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: Operating System differences and Ada OS independent programming

[Dmitry A. Kazakov]

On 2016-03-23 09:13, gautier_niouzes@hotmail.com wrote:
> On Tuesday, March 22, 2016 at 12:15:17 PM UTC+1, G.B. 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.
>
> Dmitry:
>
>> 4. Pack it again and make sure that the new archive is exactly same.
>
> No problem with all that, as long as you don't use drive letters.

Of course it is a problem, but irrelevant to the issue. There are lots 
of different things varying across file systems which make symmetry 
impossible. The most evident ones are the letter case. Less evident are 
short vs. long Windows names, the file version number under VMS, and of 
course all sorts of short-cuts, mappings, virtual devices etc.

Ada's abstraction should reflect the most generic file system properties:

- Acyclic directed graph of names built from Unicode code points;
- Multiple roots (AKA devices);
- Absolute vs. relative path distinction;
- Current directory path generator;
- Generators for special directory paths (home, my downloads, my 
documents etc);
- Extension / MIME types;
- Version / change / release number;
- Time stamps (modification, creation etc).

Note, not the least common denominator which is virtually nothing. For 
anything impossible under the given OS Use_Error is propagated.

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

Re: Operating System differences and Ada OS independent programming

[G.B.]

On 23.03.16 09:38, Dmitry A. Kazakov wrote:
> For anything impossible under the given OS Use_Error is propagated.

In some cases a substitution mechanism might work:
If "E:\" is covered by some "multiple roots" type,
and the filesystem is Unix style, the Use_Error
could be staged, and conditional. The run-time
support that establishes the type's associated behavior
(or path mapping) would be configurable. The
programmer specifies a mapping mechanism from the
"multiple roots" object representing "E:\" to some
other "multiple roots" object that can play the
same role on his or her system.  Provided, maybe,
that the original object did not specifically use
"root-ness", which could be reflected in some constant
property preventing the above mentioned mapping.

So, then, Use_Error would be raised either

- if the mapping could not be performed because the
   target object would not represent "root-ness",

- or if no mapping was provided by the programmer,

- or if the mapping "tampers with file systems",

- or if the run-time system does not support mapping.

Re: Operating System differences and Ada OS independent programming

[rieachus]

> 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. 

Obsolete maybe, but not a hack.  For Ada's initial intended uses thirty years ago, especially in embedded systems, you would commonly have multiple types of storage, and no fancy OS features to hide the differences.  On one (early) Ada project, the form string was disk, floppy, or core (yes, those little ferite doughnuts with three or four wires through them).  Very different drivers and timings, and it did what we needed nicely.  You couldn't create new files in core (no room), and the floppy drive was parked when in flight, but it was all good.

The original intent was for something like Fortran or Cobol form strings, but by the time the Ada 83 standard rolled around, for the complex marshalling and unmarshalling of records you either took the default that came with Direct_IO  or rolled your own with Low_Level_IO.  (If the compiler was being developed for the project, the vendor implemented Low_Level_IO whatever way your requirements document stated.  Most users though, didn't have that big a hammer, so they used Text_IO, Direct_IO, or Sequential_IO.)

Re: Operating System differences and Ada OS independent programming

[Shark8]

On Wednesday, March 23, 2016 at 2:39:08 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> Ada's abstraction should reflect the most generic file system properties:
> 
> - Acyclic directed graph of names built from Unicode code points;

No, these should be a private type which is 0..Unsigned_32/64 and has the name as a property whose value is a unicode string. There should be a "translate" function which takes a Unicode string and translates it into the filesystem-actual's encoding. -- an identical yet distinct type should exist for directories.

> - Multiple roots (AKA devices);

No, absolutely not.
These should NOT be part of the filesystem; instead there should be a Physical_Drive type and a Virtual_Drive type, where the former denotes a physical drive, and the virtual denotes either a single partition of a physical_drive or multiple physical drives. (VMS has the capibility to view multiple HDs as a single logical drive.)

UNIX caused all sorts of trouble with their misguided "everything's a file" stupidity.

> - Absolute vs. relative path distinction;

Yes.

> - Current directory path generator;

Pretty much unneeded if there's a directory-type:
Type FS_Rider is
  Current : Directory_Type;
  -- Other state information.
end record;

> - Generators for special directory paths (home, my downloads, my 
> documents etc);

These could be a simple map (key -> directory_type), populated as needed by the particular OS/FS.

> - Extension / MIME types;

Why?

> - Version / change / release number;

Definitely.

> - Time stamps (modification, creation etc).

Which should be Ada.Calendar.Time.

Re: Operating System differences and Ada OS independent programming

[Dmitry A. Kazakov]

On 2016-03-24 04:36, Shark8 wrote:
> On Wednesday, March 23, 2016 at 2:39:08 AM UTC-6, Dmitry A. Kazakov wrote:
>>
>> Ada's abstraction should reflect the most generic file system properties:
>>
>> - Acyclic directed graph of names built from Unicode code points;
>
> No, these should be a private type which is 0..Unsigned_32/64 and
> has  the name as a property whose value is a unicode string. There should be
> a "translate" function which takes a Unicode string and translates it
> into the filesystem-actual's encoding. -- an identical yet distinct type
> should exist for directories.

Ada does not have Unicode strings. The point is that graph nodes 
(filenames) are logically chains of code points.

>> - Multiple roots (AKA devices);
>
> No, absolutely not.

Why? Only one OS (Unix) has single root, which does not work anyway in 
presence of networking, virtual, portable file systems. In its GUI, e.g. 
GNOME Linux dropped single root concept.

>> - Current directory path generator;
>
> Pretty much unneeded if there's a directory-type:
> Type FS_Rider is
>    Current : Directory_Type;
>    -- Other state information.
> end record;

You need functions returning standard paths. E.g. (imaginary operations)

    Get_Current_Directory / "My_Folder" / "Hello_World" + "ads"

instead of

    "./My_Folder/Hello_World.ads"

>> - Extension / MIME types;
>
> Why?

Files have extensions, don't they?

>> - Version / change / release number;
>
> Definitely.
>
>> - Time stamps (modification, creation etc).
>
> Which should be Ada.Calendar.Time.

Yes, but you need operations putting them into the path.

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

Re: Operating System differences and Ada OS independent programming

[Dmitry A. Kazakov]

On 2016-03-23 16:08, G.B. wrote:
> On 23.03.16 09:38, Dmitry A. Kazakov wrote:
>> For anything impossible under the given OS Use_Error is propagated.
>
> In some cases a substitution mechanism might work:
> If "E:\" is covered by some "multiple roots" type,
> and the filesystem is Unix style, the Use_Error
> could be staged, and conditional. The run-time
> support that establishes the type's associated behavior
> (or path mapping) would be configurable. The
> programmer specifies a mapping mechanism from the
> "multiple roots" object representing "E:\" to some
> other "multiple roots" object that can play the
> same role on his or her system.  Provided, maybe,
> that the original object did not specifically use
> "root-ness", which could be reflected in some constant
> property preventing the above mentioned mapping.
>
> So, then, Use_Error would be raised either
>
> - if the mapping could not be performed because the
>    target object would not represent "root-ness",
>
> - or if no mapping was provided by the programmer,
>
> - or if the mapping "tampers with file systems",
>
> - or if the run-time system does not support mapping.

The mapping is normally predefined. E.g. when you run MinGW, Windows 
roots are already mapped:

    E:\  ->  /e/

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

Re: Operating System differences and Ada OS independent programming

[G.B.]

On 24.03.16 09:00, Dmitry A. Kazakov wrote:
> The mapping is normally predefined. E.g. when you run MinGW, Windows
> roots are already mapped:
>
>     E:\  -> /e/

Enter a microcontroller with both a flash drive attached and
some other storage connected via network. Not much of
an operating system, yet a simple, single-threaded hierarchical
file system for the flash drive.

Then, when porting a prototype version of a program from
Windows™ to the controller, I thought that the programmer,
or "operator", should be able to instruct the run-time that

- "E:\" should be mapped to something that represents the "root"
of the filesystem on the flash drive, and

- %HOMEDRIVE% be mapped to the network attached thing,

- %HOMEPATH% to below what %HOMEDRIVE% has become.

If the program was developed without many features required
of the file system, then the source text that names files
would not need to be recompiled by any configurable implementation
of Ada.

Re: Operating System differences and Ada OS independent programming

[G.B.]

On 24.03.16 11:41, G.B. wrote:
> If the program was developed without many features required
> of the file system, then the source text that names files
> would not need to be recompiled by any configurable implementation
> of Ada.

"edited for", I meant.

Re: Operating System differences and Ada OS independent programming

[Dennis Lee Bieber]

On Thu, 24 Mar 2016 08:58:01 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> declaimed the following:

>
>Files have extensions, don't they?
>
	They didn't on Xerox CP/V -- files were identified by, as I recall, a
32 character string (which could, as I'd done it a few times, include a
<bel> character). Optionally there were fields for user account (to access
files belonging to a different account) and/or password.

32char.account.password

	At my college, it was a convention to preface file names with:

S:		source
R:		ROM (relocatable object module)
L:		LMN (load module, aka "executable", no idea where the N came from)

but those prefaces were just part of the file name and not an OS supported
structure.

	AmigaOS didn't require extensions either; only Workbench (the graphical
environment) required them -- files that were to show up on the Workbench
required a companion 	samename.info		file which contained
information on whether the file was an application or data (data .info held
the path of the executable application that handles the associated file),
the icon graphics for the file, "command line arguments" for invocation,
etc.

	Extensions were used as a convention by tools such as compilers, to
differentiate headers from bodies, object files, etc. But the OS did not
track them as a field separate from the name itself.

	Not like CP/M, TRSDOS, MS-DOS, and related -- the slew of "8.3"
directory structures where extensions had a separate location in the
directory and the "." (or TRSDOS "/") were just separators.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Operating System differences and Ada OS independent programming

[Dmitry A. Kazakov]

On 2016-03-24 11:41, G.B. wrote:
> On 24.03.16 09:00, Dmitry A. Kazakov wrote:
>> The mapping is normally predefined. E.g. when you run MinGW, Windows
>> roots are already mapped:
>>
>>     E:\  -> /e/
>
> Enter a microcontroller with both a flash drive attached and
> some other storage connected via network. Not much of
> an operating system, yet a simple, single-threaded hierarchical
> file system for the flash drive.
>
> Then, when porting a prototype version of a program from
> Windows™ to the controller, I thought that the programmer,
> or "operator", should be able to instruct the run-time that
 >
> - "E:\" should be mapped to something that represents the "root"
> of the filesystem on the flash drive, and
>
> - %HOMEDRIVE% be mapped to the network attached thing,
>
> - %HOMEPATH% to below what %HOMEDRIVE% has become.

OS user (operator), yes, programmer, as Ada programmer, no. Configuring 
the system environment is not the objective of the program. An Ada 
program deals with the existing environment.

So basically it is not Ada standard library concern. It will have a 
"home directory" path generator function, implemented somehow. Thus the 
programmer will be able to express "hello_world Ada body file from home 
directory" in a system-independent way.

> If the program was developed without many features required
> of the file system, then the source text that names files
> would not need to be recompiled by any configurable implementation
> of Ada.

Yes, because file systems have similar properties expressed differently 
when paths are strings. That is why path must be a proper type instead.

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