<head>
<title></title>
</head>
<body>
<div class="userStyles" style=" font-family: Arial; font-size: 12pt; color: #000000;">ETH-Zurich reorganized their server.<br>
<br>
Updated URL:<br>
<br>
<a href="https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/147091/eth-26082-02.pdf">https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/147091/eth-26082-02.pdf</a><br>
<footer class="replyforwardcontainer"><br>
<br>
<span>On Fri, 23 Apr 2021 14:53:44 -0700, peter@easthope.ca wrote:</span><br>
<br>
From: Joerg <joerg.straube@ia....ch><br>
Date: Fri, 23 Apr 2021 05:26:32 +0200<br>
> The main drawback of the ProjectOberon system as of today is that Files.Mod i=<br>
> s directly bound to the implementation of the Oberon file system and is not o=<br>
> nly a dispatcher with PROCEDURE variables.<br>
> ... easily=E2=80=9C bind another file system t=<br>
> o the Files interface and all modules using Files can benefit of this new im=<br>
> plementation, even the Oberon system itself.<br>
<br>
Hello Joerg,<br>
My knowledge is superficial but your explanation reminds of Section<br>
6.1.1, page 100, in the Ph.D. thesis of Pieter Muller.<br>
http://e-collection.ethbib.ethz.ch/ecol-pool/diss/fulltext/eth14755.pdf<br>
<br>
"In Native Oberon, there was a need to allow many kinds of file<br>
system for interoperability with other operating systems installed on the<br>
same machine, to access several kinds of removable media with their own<br>
file system formats, and to access file systems located on remote servers.<br>
The installable file system framework developed for Native Oberon ..."<br>
<br>
Put an updated ETH Oberon on a Skulski machine?<br>
<br>
Regards, ... P. L.<br>
<br>
--<br>
VoIP: +1 604 670 0140 Bcc: peter at easthope. ca<br>
<br>
--<br>
Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems<br>
https://lists.inf.ethz.ch/mailman/listinfo/oberon</joerg.straube@ia....ch><br>
</footer>
</div>
</body>