Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » Host.FST for emulators.
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Host.FST for emulators. [message #380495] Fri, 01 February 2019 19:50 Go to next message
Anonymous
Karma:
Originally posted by: Leon Sargent

I see that GSPlus and I believe GSPort have support for Host.FST.

I can not seem to find docs for install and usage.

Anyone point in the right direction?

Leon
Re: Host.FST for emulators. [message #380507 is a reply to message #380495] Sat, 02 February 2019 04:29 Go to previous messageGo to next message
mverpelli is currently offline  mverpelli
Messages: 289
Registered: May 2013
Karma: 0
Senior Member
On Saturday, February 2, 2019 at 1:50:54 AM UTC+1, Leon Sargent wrote:
> I see that GSPlus and I believe GSPort have support for Host.FST.
>
> I can not seem to find docs for install and usage.
>
> Anyone point in the right direction?
>
> Leon

I can say how I did with Windows:

1) I put ATInit in the root folder
2) in the config.txt file I modified the line:
g_cfg_host_path = C:/Users/<your name here>/Documents/Host

Marco

P.S. it works even if you start ProDOS 8 bits.
Re: Host.FST for emulators. [message #380514 is a reply to message #380507] Sat, 02 February 2019 11:44 Go to previous messageGo to next message
Hugh Hood is currently offline  Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
Senior Member
Marco,

As you are using this with Windows, may I ask (2) questions?

1. Kelvin's site states:

' File Types, Finder Info, and Resource Forks are supported. '

Is that just a MacOS feature, or is that working under Windows? If the
latter, is he using XAttr to preserve the attributes (File Type, etc) or
some type of AppleDouble system where the attributes are stored in
hidden files beginning with '.'?

Sherlock is a very clever guy, but Windows support for the attributes
would be a great, great thing.


2. Is the only file you are installing the 'ATInit' file, or is there
something else? I notice that file is only 91 bytes in length, and it
would seem to need more code than that to make everything work.


Thanks. I confess that I'm late to the party on this. Somehow I had
never heard of HST.FST until you and Leon mentioned it.





Hugh Hood




On 2/2/2019 3:29 AM, Marco Verpelli wrote:
>
> I can say how I did with Windows:
>
> 1) I put ATInit in the root folder
> 2) in the config.txt file I modified the line:
> g_cfg_host_path = C:/Users/<your name here>/Documents/Host
>
> Marco
>
> P.S. it works even if you start ProDOS 8 bits.
>
Re: Host.FST for emulators. [message #380516 is a reply to message #380514] Sat, 02 February 2019 12:08 Go to previous messageGo to next message
mverpelli is currently offline  mverpelli
Messages: 289
Registered: May 2013
Karma: 0
Senior Member
On Saturday, February 2, 2019 at 5:44:20 PM UTC+1, Hugh Hood wrote:
> Marco,
>
> As you are using this with Windows, may I ask (2) questions?
>
> 1. Kelvin's site states:
>
> ' File Types, Finder Info, and Resource Forks are supported. '
>
> Is that just a MacOS feature, or is that working under Windows? If the
> latter, is he using XAttr to preserve the attributes (File Type, etc) or
> some type of AppleDouble system where the attributes are stored in
> hidden files beginning with '.'?
>
> Sherlock is a very clever guy, but Windows support for the attributes
> would be a great, great thing.
>
>
> 2. Is the only file you are installing the 'ATInit' file, or is there
> something else? I notice that file is only 91 bytes in length, and it
> would seem to need more code than that to make everything work.
>
>
> Thanks. I confess that I'm late to the party on this. Somehow I had
> never heard of HST.FST until you and Leon mentioned it.
>
>
>
>
>
> Hugh Hood
>
>
>
>
> On 2/2/2019 3:29 AM, Marco Verpelli wrote:
>>
>> I can say how I did with Windows:
>>
>> 1) I put ATInit in the root folder
>> 2) in the config.txt file I modified the line:
>> g_cfg_host_path = C:/Users/<your name here>/Documents/Host
>>
>> Marco
>>
>> P.S. it works even if you start ProDOS 8 bits.
>>

1 - I say yes, for example if I download a SHK file from some site and put it in my Host directory, when I launch the emulator I see the file with the correct icon and also the file/program association works

2 - Yes, the file ATInit is the only thing to install, I pointed out that I put it in the root because in this way it also works with ProDOS 8 bits (which is the thing that most interests me)

I learned this summer of the existence of this thing during an exchange of ideas with Dagen Brock on how to eliminate some (small) bugs from the emulator. I think it's the emulator that does all the works.

Marco
Re: Host.FST for emulators. [message #380535 is a reply to message #380514] Sat, 02 February 2019 23:23 Go to previous messageGo to next message
kelvin is currently offline  kelvin
Messages: 49
Registered: May 2013
Karma: 0
Member
Win32 support for resource forks and filetype/auxtype is via
alternate data streams. It uses the same format and naming convention
as Services For Macintosh, Microsoft's AppleShare server. Allegedly,
alternate data streams were created for that very purpose.

ATINIT is small because it doesn't have to do much. It patches
the $BF00 ProDOS MLI so GS+ can get a first shot at all MLI calls
and either handles them or passes them to the real ProDOS code.
(There are also a couple that require tail patching.)

Kelvin

In <TKCdnbaZys5DVcjBnZ2dnUU7-fXNnZ2d@earthlink.com>
Hugh Hood <hughhood@earthlink.net> writes:

> Marco,
>
> As you are using this with Windows, may I ask (2) questions?
>
> 1. Kelvin's site states:
>
> ' File Types, Finder Info, and Resource Forks are supported. '
>
> Is that just a MacOS feature, or is that working under Windows? If the
> latter, is he using XAttr to preserve the attributes (File Type, etc) or
> some type of AppleDouble system where the attributes are stored in
> hidden files beginning with '.'?
>
> Sherlock is a very clever guy, but Windows support for the attributes
> would be a great, great thing.
>
>
> 2. Is the only file you are installing the 'ATInit' file, or is there
> something else? I notice that file is only 91 bytes in length, and it
> would seem to need more code than that to make everything work.
>
>
> Thanks. I confess that I'm late to the party on this. Somehow I had
> never heard of HST.FST until you and Leon mentioned it.
>
>
>
>
>
> Hugh Hood
>
>
>
>
> On 2/2/2019 3:29 AM, Marco Verpelli wrote:
>>
>> I can say how I did with Windows:
>>
>> 1) I put ATInit in the root folder
>> 2) in the config.txt file I modified the line:
>> g_cfg_host_path = C:/Users/<your name here>/Documents/Host
>>
>> Marco
>>
>> P.S. it works even if you start ProDOS 8 bits.
>>

-------
ProLine: kelvin@pro-kegs
Re: Host.FST for emulators. [message #380538 is a reply to message #380535] Sun, 03 February 2019 00:42 Go to previous messageGo to next message
Hugh Hood is currently offline  Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
Senior Member
Kelvin,

Thanks for the explanations.

Since it appears that one can examine the stream contents from the
Windows command line by using the command 'more <FileName:StreamName>,
what phrase would I use in place of 'StreamName' if I wanted to view the
ADS data for FinderInfo? Or, are you using a different stream name for that?

Also, since Andy's CiderPress is the goto tool on Windows for dealing
with disk images, I wonder if it would it be difficult for him to
implement ADS optionally to preserve attributes rather than his current
extension method whereby the Type/Aux are appended to the filename?

It would be nice to drag and drop Apple II files between GS+ and the
Windows Desktop and keep all the ProDOS type/aux stuff intact both ways
(without relying on default file extensions).




Hugh Hood


On 2/3/2019 2:53 AM, Kelvin Sherlock wrote:
> Win32 support for resource forks and filetype/auxtype is via
> alternate data streams. It uses the same format and naming convention
> as Services For Macintosh, Microsoft's AppleShare server. Allegedly,
> alternate data streams were created for that very purpose.
>
> ATINIT is small because it doesn't have to do much. It patches
> the $BF00 ProDOS MLI so GS+ can get a first shot at all MLI calls
> and either handles them or passes them to the real ProDOS code.
> (There are also a couple that require tail patching.)
>
> Kelvin
>
> In <TKCdnbaZys5DVcjBnZ2dnUU7-fXNnZ2d@earthlink.com>
> Hugh Hood <hughhood@earthlink.net> writes:
>
>> Marco,
>>
>> As you are using this with Windows, may I ask (2) questions?
>>
>> 1. Kelvin's site states:
>>
>> ' File Types, Finder Info, and Resource Forks are supported.'
>>
>> Is that just a MacOS feature, or is that working under Windows? If the
>> latter, is he using XAttr to preserve the attributes (File Type, etc) or
>> some type of AppleDouble system where the attributes are stored in
>> hidden files beginning with '.'?
>>
>> Sherlock is a very clever guy, but Windows support for the attributes
>> would be a great, great thing.
>>
>>
>> 2. Is the only file you are installing the 'ATInit' file, or is there
>> something else? I notice that file is only 91 bytes in length, and it
>> would seem to need more code than that to make everything work.
>>
>>
>> Thanks. I confess that I'm late to the party on this. Somehow I had
>> never heard of HST.FST until you and Leon mentioned it.
>>
>>
>>
>>
>>
>> Hugh Hood
>>
>>
>>
>>
>> On 2/2/2019 3:29 AM, Marco Verpelli wrote:
>>>
>>> I can say how I did with Windows:
>>>
>>> 1) I put ATInit in the root folder
>>> 2) in the config.txt file I modified the line:
>>> g_cfg_host_path = C:/Users/<your name here>/Documents/Host
>>>
>>> Marco
>>>
>>> P.S. it works even if you start ProDOS 8 bits.
>>>
>
> -------
> ProLine: kelvin@pro-kegs
>
Re: Host.FST for emulators. [message #380545 is a reply to message #380538] Sun, 03 February 2019 11:18 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Saturday, February 2, 2019 at 9:42:32 PM UTC-8, Hugh Hood wrote:
> Also, since Andy's CiderPress is the goto tool on Windows for dealing
> with disk images, I wonder if it would it be difficult for him to
> implement ADS optionally to preserve attributes rather than his current
> extension method whereby the Type/Aux are appended to the filename?

I wasn't familiar with ADS. A quick search turned up several articles on anti-virus sites; apparently they're a popular way to conceal malware. Given that CiderPress has a history of setting off virus detectors, I'm not sure it's wise to feed the flames. :-)

It appears that ADS is an NTFS feature. Most Windows systems run on NTFS, so that shouldn't be too limiting, though ADS might not work on a file server.

> It would be nice to drag and drop Apple II files between GS+ and the
> Windows Desktop and keep all the ProDOS type/aux stuff intact both ways
> (without relying on default file extensions).

I think you'd be better off extracting to something like AppleSingle. Most Apple II files aren't directly useful when extracted in "preserve" mode anyway, so adding a file header wouldn't generally get in the way.

I really hate resource forks.
Re: Host.FST for emulators. [message #380554 is a reply to message #380538] Sun, 03 February 2019 14:11 Go to previous messageGo to next message
kelvin is currently offline  kelvin
Messages: 49
Registered: May 2013
Karma: 0
Member
Resource forks are stored in :AFP_Resource. Finder Info and file/aux types
are stored in :AFP_AfpInfo.

AFP_AfpInfo is:

#pragma pack(push, 2)
struct AFP_Info {
uint32_t magic;
uint32_t version;
uint32_t file_id;
uint32_t backup_date;
uint8_t finder_info[32];
uint16_t prodos_file_type;
uint32_t prodos_aux_type;
uint8_t reserved[6];
};
#pragma pack(pop)

magic is 0x00504641
version is 0x00010000
(little endian)
filetypes and auxtypes are stored in the specific fields as well as the
finder_info.

Kelvin

In <DdGdnTOC55rf4svBnZ2dnUU7-enNnZ2d@earthlink.com>
Hugh Hood <hughhood@earthlink.net> writes:

> Kelvin,
>
> Thanks for the explanations.
>
> Since it appears that one can examine the stream contents from the
> Windows command line by using the command 'more <FileName:StreamName>,
> what phrase would I use in place of 'StreamName' if I wanted to view the
> ADS data for FinderInfo? Or, are you using a different stream name for that?
>
> Also, since Andy's CiderPress is the goto tool on Windows for dealing
> with disk images, I wonder if it would it be difficult for him to
> implement ADS optionally to preserve attributes rather than his current
> extension method whereby the Type/Aux are appended to the filename?
>
> It would be nice to drag and drop Apple II files between GS+ and the
> Windows Desktop and keep all the ProDOS type/aux stuff intact both ways
> (without relying on default file extensions).
>
>
>
>
> Hugh Hood
>
>
> On 2/3/2019 2:53 AM, Kelvin Sherlock wrote:
>> Win32 support for resource forks and filetype/auxtype is via
>> alternate data streams. It uses the same format and naming convention
>> as Services For Macintosh, Microsoft's AppleShare server. Allegedly,
>> alternate data streams were created for that very purpose.
>>
>> ATINIT is small because it doesn't have to do much. It patches
>> the $BF00 ProDOS MLI so GS+ can get a first shot at all MLI calls
>> and either handles them or passes them to the real ProDOS code.
>> (There are also a couple that require tail patching.)
>>
>> Kelvin
>>
>> In <TKCdnbaZys5DVcjBnZ2dnUU7-fXNnZ2d@earthlink.com>
>> Hugh Hood <hughhood@earthlink.net> writes:
>>
>>> Marco,
>>>
>>> As you are using this with Windows, may I ask (2) questions?
>>>
>>> 1. Kelvin's site states:
>>>
>>> ' File Types, Finder Info, and Resource Forks are supported.'
>>>
>>> Is that just a MacOS feature, or is that working under Windows? If the
>>> latter, is he using XAttr to preserve the attributes (File Type, etc) or
>>> some type of AppleDouble system where the attributes are stored in
>>> hidden files beginning with '.'?
>>>
>>> Sherlock is a very clever guy, but Windows support for the attributes
>>> would be a great, great thing.
>>>
>>>
>>> 2. Is the only file you are installing the 'ATInit' file, or is there
>>> something else? I notice that file is only 91 bytes in length, and it
>>> would seem to need more code than that to make everything work.
>>>
>>>
>>> Thanks. I confess that I'm late to the party on this. Somehow I had
>>> never heard of HST.FST until you and Leon mentioned it.
>>>
>>>
>>>
>>>
>>>
>>> Hugh Hood
>>>
>>>
>>>
>>>
>>> On 2/2/2019 3:29 AM, Marco Verpelli wrote:
>>>>
>>>> I can say how I did with Windows:
>>>>
>>>> 1) I put ATInit in the root folder
>>>> 2) in the config.txt file I modified the line:
>>>> g_cfg_host_path = C:/Users/<your name here>/Documents/Host
>>>>
>>>> Marco
>>>>
>>>> P.S. it works even if you start ProDOS 8 bits.
>>>>
>>
>> -------
>> ProLine: kelvin@pro-kegs
>>

-------
ProLine: kelvin@pro-kegs
Re: Host.FST for emulators. [message #380643 is a reply to message #380545] Mon, 04 February 2019 11:32 Go to previous messageGo to next message
ol.sc is currently offline  ol.sc
Messages: 211
Registered: January 2013
Karma: 0
Senior Member
Hi,

> I think you'd be better off extracting to something like AppleSingle. Most=
> Apple II files aren't directly useful when extracted in "preserve" mode an=
> yway, so adding a file header wouldn't generally get in the way.

Exactly!

Therefore it would be great if CiderPress would support AppleSingle.
AppleSingle has received some momentum recently:

- It's now the default output format of the cc65 toolchain.
- AppleCommander now supports it at least partially.
- David's fork of Cadius now supports it at least partially.

Regards,
Oliver
Re: Host.FST for emulators. [message #380702 is a reply to message #380643] Tue, 05 February 2019 10:36 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Monday, February 4, 2019 at 8:32:31 AM UTC-8, Oliver Schmidt wrote:
> Therefore it would be great if CiderPress would support AppleSingle.

It does, as a read-only archive format (handling v1 and v2, as well as the bizarre things that the Mac OS X "applesingle" tool creates). You can open ".as" files and extract their contents. CP does not create them, however.
Re: Host.FST for emulators. [message #380703 is a reply to message #380507] Tue, 05 February 2019 11:24 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Leon Sargent

On Saturday, February 2, 2019 at 4:29:09 AM UTC-5, Marco Verpelli wrote:


> I can say how I did with Windows:
>
> 1) I put ATInit in the root folder

Is the ATInit an AppleTalk files from the System 6 install disk?
> 2) in the config.txt file I modified the line:
> g_cfg_host_path = C:/Users/<your name here>/Documents/Host

So. Am I to create a folder on the host system and put the mentioned ATInit file inside the folder and then configure the emulator to set the Host.FST location to that created folder?
>

Leon
Re: Host.FST for emulators. [message #380705 is a reply to message #380703] Tue, 05 February 2019 12:08 Go to previous messageGo to next message
mverpelli is currently offline  mverpelli
Messages: 289
Registered: May 2013
Karma: 0
Senior Member
On Tuesday, February 5, 2019 at 5:24:16 PM UTC+1, Leon Sargent wrote:
> On Saturday, February 2, 2019 at 4:29:09 AM UTC-5, Marco Verpelli wrote:
>
>
>> I can say how I did with Windows:
>>
>> 1) I put ATInit in the root folder
>
> Is the ATInit an AppleTalk files from the System 6 install disk?
>> 2) in the config.txt file I modified the line:
>> g_cfg_host_path = C:/Users/<your name here>/Documents/Host
>
> So. Am I to create a folder on the host system and put the mentioned ATInit file inside the folder and then configure the emulator to set the Host.FST location to that created folder?
>>
>
> Leon

I'm sorry if I was not clear enough but the less I write in English the less mistakes I make.

Is the ATInit from

https://github.com/ksherlock/host-fst/releases/download/r3/h ost.mli.po

and I put it in the root folder of the GSOS 6.0.4, I mean in the HD image from which the emulator boots.

then create a folder in the host system and change config.txt

Marco
Re: Host.FST for emulators. [message #380760 is a reply to message #380702] Wed, 06 February 2019 09:39 Go to previous messageGo to next message
ol.sc is currently offline  ol.sc
Messages: 211
Registered: January 2013
Karma: 0
Senior Member
On Tue, 5 Feb 2019 07:36:06 -0800 (PST), fadden <thefadden@gmail.com>
wrote:

> On Monday, February 4, 2019 at 8:32:31 AM UTC-8, Oliver Schmidt wrote:
>> Therefore it would be great if CiderPress would support AppleSingle.
>
> It does, as a read-only archive format (handling v1 and v2, as well as the bizarre things that the Mac OS X "applesingle" tool creates). You can open ".as" files and extract their contents. CP does not create them, however.

Okay then I was too unprecise...

It would be great if CiderPress would support AppleSingle as an
alternative means for "file attribute preservation".

Trying to be even more specific...

On file extraction create an AppleSingle file with a single data fork
and on file addition read an AppleSingle file with a single data fork.

As replacement for the current "file attribute preservation" those
AppleSingle files need just two entries:
- ID 1 aka Data Fork
- ID 11 aka ProDOS File Info

This is the template used by cc65:
https://github.com/cc65/cc65/blob/master/libsrc/apple2/exehd r.s#L26-L39

Regards,
Oliver
Re: Host.FST for emulators. [message #380802 is a reply to message #380554] Wed, 06 February 2019 22:08 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Matthew Carlson

On Sunday, February 3, 2019 at 9:20:19 AM UTC-8, Kelvin Sherlock wrote:
> Resource forks are stored in :AFP_Resource. Finder Info and file/aux types
> are stored in :AFP_AfpInfo.
>
> AFP_AfpInfo is:
>
> #pragma pack(push, 2)
> struct AFP_Info {
> uint32_t magic;
> uint32_t version;
> uint32_t file_id;
> uint32_t backup_date;
> uint8_t finder_info[32];
> uint16_t prodos_file_type;
> uint32_t prodos_aux_type;
> uint8_t reserved[6];
> };
> #pragma pack(pop)
>
> magic is 0x00504641
> version is 0x00010000
> (little endian)
> filetypes and auxtypes are stored in the specific fields as well as the
> finder_info.
>
> Kelvin
>
> In <DdGdnTOC55rf4svBnZ2dnUU7-enNnZ2d@earthlink.com>
> Hugh Hood <hughhood@earthlink.net> writes:
>
>> Kelvin,
>>
>> Thanks for the explanations.
>>
>> Since it appears that one can examine the stream contents from the
>> Windows command line by using the command 'more <FileName:StreamName>,
>> what phrase would I use in place of 'StreamName' if I wanted to view the
>> ADS data for FinderInfo? Or, are you using a different stream name for that?
>>
>> Also, since Andy's CiderPress is the goto tool on Windows for dealing
>> with disk images, I wonder if it would it be difficult for him to
>> implement ADS optionally to preserve attributes rather than his current
>> extension method whereby the Type/Aux are appended to the filename?
>>
>> It would be nice to drag and drop Apple II files between GS+ and the
>> Windows Desktop and keep all the ProDOS type/aux stuff intact both ways
>> (without relying on default file extensions).
>>
>>
>>
>>
>> Hugh Hood
>>
>>
>> On 2/3/2019 2:53 AM, Kelvin Sherlock wrote:
>>> Win32 support for resource forks and filetype/auxtype is via
>>> alternate data streams. It uses the same format and naming convention
>>> as Services For Macintosh, Microsoft's AppleShare server. Allegedly,
>>> alternate data streams were created for that very purpose.
>>>
>>> ATINIT is small because it doesn't have to do much. It patches
>>> the $BF00 ProDOS MLI so GS+ can get a first shot at all MLI calls
>>> and either handles them or passes them to the real ProDOS code.
>>> (There are also a couple that require tail patching.)
>>>
>>> Kelvin
>>>
>>> In <TKCdnbaZys5DVcjBnZ2dnUU7-fXNnZ2d@earthlink.com>
>>> Hugh Hood <hughhood@earthlink.net> writes:
>>>
>>>> Marco,
>>>>
>>>> As you are using this with Windows, may I ask (2) questions?
>>>>
>>>> 1. Kelvin's site states:
>>>>
>>>> ' File Types, Finder Info, and Resource Forks are supported.'
>>>>
>>>> Is that just a MacOS feature, or is that working under Windows? If the
>>>> latter, is he using XAttr to preserve the attributes (File Type, etc) or
>>>> some type of AppleDouble system where the attributes are stored in
>>>> hidden files beginning with '.'?
>>>>
>>>> Sherlock is a very clever guy, but Windows support for the attributes
>>>> would be a great, great thing.
>>>>
>>>>
>>>> 2. Is the only file you are installing the 'ATInit' file, or is there
>>>> something else? I notice that file is only 91 bytes in length, and it
>>>> would seem to need more code than that to make everything work.
>>>>
>>>>
>>>> Thanks. I confess that I'm late to the party on this. Somehow I had
>>>> never heard of HST.FST until you and Leon mentioned it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hugh Hood
>>>>
>>>>
>>>>
>>>>
>>>> On 2/2/2019 3:29 AM, Marco Verpelli wrote:
>>>> >
>>>> > I can say how I did with Windows:
>>>> >
>>>> > 1) I put ATInit in the root folder
>>>> > 2) in the config.txt file I modified the line:
>>>> > g_cfg_host_path = C:/Users/<your name here>/Documents/Host
>>>> >
>>>> > Marco
>>>> >
>>>> > P.S. it works even if you start ProDOS 8 bits.
>>>> >
>>>
>>> -------
>>> ProLine: kelvin@pro-kegs
>>>
>
> -------
> ProLine: kelvin@pro-kegs

Very nice work here. This is something that we have all wanted for a very long time. I am now working to migrate my entire Apple IIgs library (life ;)) to this Host FST virtual file system. However, I have one concern and that is being able to migrate this data between platforms. (I am on Mac OS X and won't be buying another Mac.)

Looking at the code I see this for Win32.
static HANDLE open_resource_fork(const char *path, word16 *access, word16 *error) {

char *rpath = host_gc_append_string(path, ":AFP_Resource");

HANDLE h = INVALID_HANDLE_VALUE;
for (;;) {
....

For Mac OS X I see this.
#if defined(__APPLE__)
static int open_resource_fork(const char *path, word16 *access, word16 *error) {
// os x / hfs/apfs don't need to specifically create a resource fork.
// or do they?

char *rpath = host_gc_append_path(path, _PATH_RSRCFORKSPEC);

int fd = -1;
for (;;) {

For Linux I see this :(.
#elif defined __linux__
static int open_resource_fork(const char *path, word16 *access, word16 *error) {
*error = resForkNotFound;
return -1;
}

I understand that you don't want to have any little strange ._ files sitting in the directories that people/software may delete. But, how can I migrate the data between Mac, Windows and Linux otherwise? (Without putting it all on 32MB IIgs partitions again in GS/OS.) Is there a tool that will migrate metadata between file systems? How do you back it up on Windows? Can WinRAR store this data?

I was hoping to just use the Linux code, which I assumed would create a ._ file or something. But, there isn't any Linux code ;(? It looks like the ._ file naming was thought of in this code (some comments have it). Am I missing something here?

Thanks again.
Re: Host.FST for emulators. [message #380823 is a reply to message #380802] Thu, 07 February 2019 11:13 Go to previous messageGo to next message
Hugh Hood is currently offline  Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
Senior Member
in article a3510403-6b65-405c-8043-55a1bfb723f0@googlegroups.com, Matthew
Carlson at google2@mcarlson.com wrote on 2/6/19 9:08 PM:


>
> Very nice work here. This is something that we have all wanted for a very long
> time. I am now working to migrate my entire Apple IIgs library (life ;)) to
> this Host FST virtual file system. However, I have one concern and that is
> being able to migrate this data between platforms. (I am on Mac OS X and won't
> be buying another Mac.)
>

Matthew,

As my current environment involves Apple II, Windows 10 and Mac OS X
computers (and Apple II emulators on the latter two), I share your interest
in preserving attributes across the various platforms.

Based on Kelvin's post, I've begun experimenting with using 'Alternate Data
Streams' (called 'Named Streams' in Windows) to preserve attributes when
transferring files between my Windows 10 SMB server and my Mac OS X client.

Currently (without ADS), the Mac writes AppleDouble (._) files on the
Windows Server, which is not the method that Host.FST/GSPlus uses.

Since I've begun playing with a few server/client settings, the Mac will
write *some* of the XAttr attributes from Apple II (and Mac) files on the
Windows machine as 'named streams'.

FWIW, it is not *yet* writing the important stuff from the XAttr
(FinderInfo/AFP_Info), but rather is writing two *other* XAttr that Kelvin
Sherlock's ShrinkFit X utility adds to unshrunk Apple II files.

Apparently any NTFS device can support these streams, so it may be a viable
method of attribute preservation between platforms.

OTOH, named streams/ADS are not supported on some file systems.

In any case, assuming I can get FinderInfo XAttr attributes to be written
from the Mac as a 'named stream' on the Windows server, I'll post the
details.





Hugh Hood
Re: Host.FST for emulators. [message #380847 is a reply to message #380823] Fri, 08 February 2019 02:27 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Matthew Carlson

On Thursday, February 7, 2019 at 8:13:51 AM UTC-8, Hugh Hood wrote:
> in article a3510403-6b65-405c-8043-55a1bfb723f0@googlegroups.com, Matthew
> Carlson at google2@mcarlson.com wrote on 2/6/19 9:08 PM:
>
>
>>
>> Very nice work here. This is something that we have all wanted for a very long
>> time. I am now working to migrate my entire Apple IIgs library (life ;)) to
>> this Host FST virtual file system. However, I have one concern and that is
>> being able to migrate this data between platforms. (I am on Mac OS X and won't
>> be buying another Mac.)
>>
>
> Matthew,
>
> As my current environment involves Apple II, Windows 10 and Mac OS X
> computers (and Apple II emulators on the latter two), I share your interest
> in preserving attributes across the various platforms.
>
> Based on Kelvin's post, I've begun experimenting with using 'Alternate Data
> Streams' (called 'Named Streams' in Windows) to preserve attributes when
> transferring files between my Windows 10 SMB server and my Mac OS X client.
>
> Currently (without ADS), the Mac writes AppleDouble (._) files on the
> Windows Server, which is not the method that Host.FST/GSPlus uses.
>
> Since I've begun playing with a few server/client settings, the Mac will
> write *some* of the XAttr attributes from Apple II (and Mac) files on the
> Windows machine as 'named streams'.
>
> FWIW, it is not *yet* writing the important stuff from the XAttr
> (FinderInfo/AFP_Info), but rather is writing two *other* XAttr that Kelvin
> Sherlock's ShrinkFit X utility adds to unshrunk Apple II files.
>
> Apparently any NTFS device can support these streams, so it may be a viable
> method of attribute preservation between platforms.
>
> OTOH, named streams/ADS are not supported on some file systems.
>
> In any case, assuming I can get FinderInfo XAttr attributes to be written
> from the Mac as a 'named stream' on the Windows server, I'll post the
> details.
>
>
>
>
>
> Hugh Hood

Ya, I have been trying the same thing. But, there are a number of issues with the "let's keep it as metadata but migrate that between platforms approach."

1. We are assuming that using Mac OS X to copy GSPlus Mac OS X Host.FST files to a Windows system over a network share will put the file metadata into Windows ADS the same way that the GSPlus code does on Windows. I don't think that is the case. I am still setting up the emulators on both Mac OS X and Windows to test this but this is what Mac resource forks look like on Windows after a file share copy.

dir /R
---------
14 test file.txt
63 test file.txt:com.apple.metadatakMDItemFinderComment:$DATA
42 test file.txt:com.apple.metadata_kMDItemUserTags:$DATA
4 test file.txt:com.macromates.selectionRange:$DATA
1 test file.txt:com.macromates.visibleIndex:$DATA


2. You have to have a working Mac to do this. Once my Macbook Pro dies I am moving back to Windows. I have yet to find a utility that will backup Mac file system metadata and restore it on Windows ADS.


I think the goal here really is to show the file metadata on the Mac Finder.. You don't get to see it Windows. But, I can see the merits of doing the work and figuring out a way to use a platforms file system metadata for this.. The good news is that WinRAR will backup ADS streams on Windows. So at least if you know what you are doing and tell it to you can back it up. However, the Mac rar command line tool they (rarlab) also provide will not backup Mac metadata. So that cannot be used to transfer.
Re: Host.FST for emulators. [message #380857 is a reply to message #380802] Fri, 08 February 2019 10:05 Go to previous messageGo to next message
Jeff Blakeney is currently offline  Jeff Blakeney
Messages: 125
Registered: September 2013
Karma: 0
Senior Member
On 2019-02-06 10:08 p.m., Matthew Carlson wrote:
> I understand that you don't want to have any little strange ._ files
> sitting in the directories that people/software may delete. But, how
> can I migrate the data between Mac, Windows and Linux otherwise?
> (Without putting it all on 32MB IIgs partitions again in GS/OS.) Is
> there a tool that will migrate metadata between file systems? How do
> you back it up on Windows? Can WinRAR store this data?

BinaryII was created for maintaining file type information on foreign
file systems and worked quite well. BXY files became the standard for
moving files around as they were SHK files in a BinaryII wrapper. The
only problem is that BinaryII didn't support forked files. There was a
draft of a new version of BinaryII that added support for forked files
but no software seems to have implemented it.

In the Mac world, they implemented something similar called MacBinary
which does support forked files. Spectrum for the IIgs has an option to
automatically add and/or remove MacBinary headers from files it uploads
and downloads to be able to preserve file type information and resource
forks.

Apple's AppleSingle format is very similar to MacBinary as they both
store the data and resource forks in a single file with a header that
contains the file type and resource fork information.

AppleDouble format seems to have become the more popular format as it
left the data fork as a single file that could be edited like normal on
the foreign file system and the resource fork is stored in a file with a
name starting with "._". This extra file was often marked hidden so
that it wouldn't clutter up directory listings.

That's the way I remember things. I'm not really sure what the best way
to go is. I would prefer things to be in a single file but I also think
it would be nice to be able to edit the data fork on other file systems
but that isn't easily accomplished if the file contains a header and
resource data as well.
Re: Host.FST for emulators. [message #380881 is a reply to message #380802] Sat, 09 February 2019 19:29 Go to previous messageGo to next message
gids.rs is currently offline  gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
Senior Member
On Wednesday, February 6, 2019 at 9:08:13 PM UTC-6, Matthew Carlson wrote:
> On Sunday, February 3, 2019 at 9:20:19 AM UTC-8, Kelvin Sherlock wrote:
>> Resource forks are stored in :AFP_Resource. Finder Info and file/aux types
>> are stored in :AFP_AfpInfo.

....

> Very nice work here. This is something that we have all wanted for a very long time. I am now working to migrate my entire Apple IIgs library (life ;)) to this Host FST virtual file system. However, I have one concern and that is being able to migrate this data between platforms. (I am on Mac OS X and won't be buying another Mac.)

....

> I understand that you don't want to have any little strange ._ files sitting in the directories that people/software may delete. But, how can I migrate the data between Mac, Windows and Linux otherwise? (Without putting it all on 32MB IIgs partitions again in GS/OS.) Is there a tool that will migrate metadata between file systems? How do you back it up on Windows? Can WinRAR store this data?
>
> I was hoping to just use the Linux code, which I assumed would create a ._ file or something. But, there isn't any Linux code ;(? It looks like the .._ file naming was thought of in this code (some comments have it). Am I missing something here?
>


I am a little lost with regards to what you want to do with the resource fork, since it can only be used under GSOS and on a Prodos volume. Why wouldn't you want all files that are meant to be run under GSOS to be on 32 Mb Prodos volumes.

I don't know if this would help you, but someone wrote a program that converts a forked file to a directory and inside the directory the data and resource forks are separated into separate files where the data file is usually type text or binary. Runs under Prodos8 and does the entire volume in one pass. You can discard the resource fork or re-combine the files back into a forked file after the copying has been done if desired.

Another option is to put all files on an HFS cd image which can be read on both a Mac or PC machine (using CiderPress or a GS emulator that supports cd's) which also preserves the attributes and forks. A 640 Mb cd, when full, can be compressed with .zip to make the transfer easier as well.

I uploaded a compressed HFS cd image somewhere, but don't know where the link is now, but an empty HFS cd image compresses down to only 640 kb zip file. You will be able to stored forked files without losing attributes on an HFS cd.
Re: Host.FST for emulators. [message #380885 is a reply to message #380823] Sat, 09 February 2019 22:20 Go to previous messageGo to next message
Hugh Hood is currently offline  Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
Senior Member
On 2/7/2019 10:13 AM, Hugh Hood wrote:
>
> In any case, assuming I can get FinderInfo XAttr attributes to be written
> from the Mac as a 'named stream' on the Windows server, I'll post the
> details.
>

Despite my best efforts, this has been a 'no go' for me on my OS X
10.4.11 (Tiger) client.

It appears that the Samba vfs module 'darwin_streams' is required to
enable named stream support (for AFP_AfpInfo) on the Mac client, and
Tiger lacks this module . I did try to add that module from my 10.5
(Leopard) installation, but it was compiled for G4/Intel only, and my
Tiger Mac is a 1 GHz G3. I didn't find any source code for it.

Sheesh. All that effort just because I was curious to see if it would
work. Even if it had, I still have questions about its usefulness, given
all the portability concerns that Matthew and the rest of you have
addressed.

I'm glad I'm in the middle of an Apple II project. It's more satisfying. ;-)





Hugh Hood
Re: Host.FST for emulators. [message #381153 is a reply to message #380847] Sat, 16 February 2019 11:22 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Matthew Carlson

On Thursday, February 7, 2019 at 11:27:54 PM UTC-8, Matthew Carlson wrote:
> On Thursday, February 7, 2019 at 8:13:51 AM UTC-8, Hugh Hood wrote:
>> in article a3510403-6b65-405c-8043-55a1bfb723f0@googlegroups.com, Matthew
>> Carlson at google2@mcarlson.com wrote on 2/6/19 9:08 PM:
>>
>>
>>>
>>> Very nice work here. This is something that we have all wanted for a very long
>>> time. I am now working to migrate my entire Apple IIgs library (life ;)) to
>>> this Host FST virtual file system. However, I have one concern and that is
>>> being able to migrate this data between platforms. (I am on Mac OS X and won't
>>> be buying another Mac.)
>>>
>>
>> Matthew,
>>
>> As my current environment involves Apple II, Windows 10 and Mac OS X
>> computers (and Apple II emulators on the latter two), I share your interest
>> in preserving attributes across the various platforms.
>>
>> Based on Kelvin's post, I've begun experimenting with using 'Alternate Data
>> Streams' (called 'Named Streams' in Windows) to preserve attributes when
>> transferring files between my Windows 10 SMB server and my Mac OS X client.
>>
>> Currently (without ADS), the Mac writes AppleDouble (._) files on the
>> Windows Server, which is not the method that Host.FST/GSPlus uses.
>>
>> Since I've begun playing with a few server/client settings, the Mac will
>> write *some* of the XAttr attributes from Apple II (and Mac) files on the
>> Windows machine as 'named streams'.
>>
>> FWIW, it is not *yet* writing the important stuff from the XAttr
>> (FinderInfo/AFP_Info), but rather is writing two *other* XAttr that Kelvin
>> Sherlock's ShrinkFit X utility adds to unshrunk Apple II files.
>>
>> Apparently any NTFS device can support these streams, so it may be a viable
>> method of attribute preservation between platforms.
>>
>> OTOH, named streams/ADS are not supported on some file systems.
>>
>> In any case, assuming I can get FinderInfo XAttr attributes to be written
>> from the Mac as a 'named stream' on the Windows server, I'll post the
>> details.
>>
>>
>>
>>
>>
>> Hugh Hood
>
> Ya, I have been trying the same thing. But, there are a number of issues with the "let's keep it as metadata but migrate that between platforms approach."
>
> 1. We are assuming that using Mac OS X to copy GSPlus Mac OS X Host.FST files to a Windows system over a network share will put the file metadata into Windows ADS the same way that the GSPlus code does on Windows. I don't think that is the case. I am still setting up the emulators on both Mac OS X and Windows to test this but this is what Mac resource forks look like on Windows after a file share copy.
>
> dir /R
> ---------
> 14 test file.txt
> 63 test file.txt:com.apple.metadatakMDItemFinderComment:$DATA
> 42 test file.txt:com.apple.metadata_kMDItemUserTags:$DATA
> 4 test file.txt:com.macromates.selectionRange:$DATA
> 1 test file.txt:com.macromates.visibleIndex:$DATA
>
>
> 2. You have to have a working Mac to do this. Once my Macbook Pro dies I am moving back to Windows. I have yet to find a utility that will backup Mac file system metadata and restore it on Windows ADS.
>
>
> I think the goal here really is to show the file metadata on the Mac Finder. You don't get to see it Windows. But, I can see the merits of doing the work and figuring out a way to use a platforms file system metadata for this. The good news is that WinRAR will backup ADS streams on Windows. So at least if you know what you are doing and tell it to you can back it up. However, the Mac rar command line tool they (rarlab) also provide will not backup Mac metadata. So that cannot be used to transfer.


After testing on both Mac OS X Mojave and Windows 10 I have found some interesting results.

This is what a Host.FST file looks like on Mac OS X.
----------------------------------------------------
$ xattr -l ./Finder.Data
com.apple.FinderInfo:
00000000 70 C9 00 00 70 64 6F 73 00 00 00 00 00 00 00 00 |p...pdos.........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.................|
00000020
$ xattr -l ./testfile
com.apple.FinderInfo:
00000000 70 50 54 45 70 64 6F 73 00 00 00 00 00 00 00 00 |pPTEpdos.........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.................|
00000020
com.apple.ResourceFork:
00000000 00 00 00 00 8C 00 00 00 3E 01 00 00 00 00 00 00 |........>........|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.................|
....


This is what it looks like after being copied to a Windows 10 system over SMB file sharing.
-----------------------------------------------------
dir /R
02/16/2019 07:13 AM 60 Finder.Data
60 Finder.Data:AFP_AfpInfo:$DATA
02/16/2019 06:16 AM 20 testfile
60 testfile:AFP_AfpInfo:$DATA
537 testfile:AFP_Resource:$DATA


The following Apple metadata is being translated during the transfer.
-----------------------------------------------------
com.apple.FinderInfo -> AFP_AfpInfo
com.apple.ResourceFork -> AFP_Resource


Note that this does not happen for other Mac OS X attributes.
-----------------------------------------------------
xattr -l ./test\ file.txt
com.apple.metadata:_kMDItemUserTags:
00000000 62 70 6C 69 73 74 30 30 A0 08 00 00 00 00 00 00 |bplist00.........|
00000010 01 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 |.................|
00000020 00 00 00 00 00 00 00 00 00 09 |..........|
0000002a
com.apple.metadata:kMDItemFinderComment:
00000000 62 70 6C 69 73 74 30 30 5F 10 13 53 6F 6D 65 20 |bplist00_..Some |
00000010 63 6F 6D 6D 65 6E 74 73 20 74 65 78 74 2E 08 00 |comments text....|
00000020 00 00 00 00 00 01 01 00 00 00 00 00 00 00 01 00 |.................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1E |...............|
0000003f
com.macromates.selectionRange: 1:15
com.macromates.visibleIndex: 0

dir /R
14 test file.txt
63 test file.txt:com.apple.metadatakMDItemFinderComment:$DATA
42 test file.txt:com.apple.metadata_kMDItemUserTags:$DATA
4 test file.txt:com.macromates.selectionRange:$DATA
1 test file.txt:com.macromates.visibleIndex:$DATA


Copying the data back reverses the translation and it works with GSplus running on Windows. So, if you use a Windows file share to migrate the Host.FST directory structure between Mac OS X and Windows, you can migrate the data. At least right now. I don't know why (I suspect Windows) is doing this translation. Probably because in the past these were the only two attributes Apple had. Obviously the developer who wrote this code knew about this. It is very neat. We just really need documentation ;).

However, I haven't yet found a utility that will do this translation in a file archive (zip, rar, tar, etc...). So you need to have a working Mac.

I am not sure if this is the "best" way to go here. Resource forks are critical for old GS/OS and Mac OS apps. Much more than metadata is stored in them (unlike today). Separate files could definitely lead to issues. But, something that is compatible with Ciderpress/AppleCommander would be a cool thing. Which in this case would essentially make them archive utilities that would work with the Host.FST directory structure in a portable manner.
Re: Host.FST for emulators. [message #381155 is a reply to message #380705] Sat, 16 February 2019 11:51 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Matthew Carlson

On Tuesday, February 5, 2019 at 9:08:05 AM UTC-8, Marco Verpelli wrote:
> On Tuesday, February 5, 2019 at 5:24:16 PM UTC+1, Leon Sargent wrote:
>> On Saturday, February 2, 2019 at 4:29:09 AM UTC-5, Marco Verpelli wrote:
>>
>>
>>> I can say how I did with Windows:
>>>
>>> 1) I put ATInit in the root folder
>>
>> Is the ATInit an AppleTalk files from the System 6 install disk?
>>> 2) in the config.txt file I modified the line:
>>> g_cfg_host_path = C:/Users/<your name here>/Documents/Host
>>
>> So. Am I to create a folder on the host system and put the mentioned ATInit file inside the folder and then configure the emulator to set the Host.FST location to that created folder?
>>>
>>
>> Leon
>
> I'm sorry if I was not clear enough but the less I write in English the less mistakes I make.
>
> Is the ATInit from
>
> https://github.com/ksherlock/host-fst/releases/download/r3/h ost.mli.po
>
> and I put it in the root folder of the GSOS 6.0.4, I mean in the HD image from which the emulator boots.
>
> then create a folder in the host system and change config.txt
>
> Marco

Just putting the atinit file from:

https://github.com/ksherlock/host-fst/releases/download/r3/h ost.mli.po

in the root of GS/OS 6.0.4 does not work for me. I don't see the Host folder on the desktop (like with the host.fst driver). Also, when I launch Basic..System I can't access /HOST. Speaking of which, I could not find that directory documented anywhere. I had to look at this code to find it. I could also not find a Prodos command to list all disks. But, I suspect that would not work here anyway.

https://github.com/digarok/gsplus/blob/master/src/host_mli.c

static char *is_host_path(unsigned pathname) {
/* add + 5 below to skip past the /HOST/ part */
/* (prefix may be missing trailing / ) */
char *p = get_pstr(pathname);
if (!p) return NULL;
if (*p == '/') {
if (!strncasecmp(p, "/HOST", 5)) {
if (p[5] == 0) return "/";
if (p[5] == '/') return p + 5;
}
return NULL;
}

if (saved_prefix) {
return host_gc_append_path(saved_prefix + 5, p);
}
return NULL;
}


If I boot up the host.mli.po disk I can do a cat of /HOST, including creating directories in it but I cannot do a prefix /HOST. So I cannot actually change the Prodos working directory to it.

Am I missing something? Thanks
Re: Host.FST for emulators. [message #381157 is a reply to message #380705] Sat, 16 February 2019 15:06 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Leon Sargent

Marco.

Took me a bit but, following your directions I now have the host share.

Very nice.

Thank you.

Leon
Re: Host.FST for emulators. [message #381199 is a reply to message #381155] Sun, 17 February 2019 15:05 Go to previous messageGo to next message
kelvin is currently offline  kelvin
Messages: 49
Registered: May 2013
Karma: 0
Member
ATINIT is only for ProDOS 8. For GS/OS, you need to install the
Host.Driver and Host.FST files into your system folder (*:System:Drivers:
and *:System:FSTs:, respectively).

Under P8, you should be able to PREFIX /HOST. That was originally tested
with BASIC and Exerciser.

-------
ProLine: kelvin@pro-kegs
Re: Host.FST for emulators. [message #381284 is a reply to message #381199] Tue, 19 February 2019 13:21 Go to previous messageGo to next message
kelvin is currently offline  kelvin
Messages: 49
Registered: May 2013
Karma: 0
Member
Addendum: I retested and PREFIX is broken (it would let you prefix to
something that isn't a directory but not to a directory). The month is also
off in timestamps. The next version of GS+ should include the fixes.

In <q4c8ko$ptg$1@dont-email.me> kelvin@pro-kegs.uucp (Kelvin Sherlock) writes:

> ATINIT is only for ProDOS 8. For GS/OS, you need to install the
> Host.Driver and Host.FST files into your system folder (*:System:Drivers:
> and *:System:FSTs:, respectively).
>
> Under P8, you should be able to PREFIX /HOST. That was originally tested
> with BASIC and Exerciser.
>
> -------
> ProLine: kelvin@pro-kegs

-------
ProLine: kelvin@pro-kegs
Re: Host.FST for emulators. [message #381295 is a reply to message #381284] Tue, 19 February 2019 20:10 Go to previous message
Anonymous
Karma:
Originally posted by: Matthew Carlson

On Tuesday, February 19, 2019 at 10:20:10 AM UTC-8, Kelvin Sherlock wrote:
> Addendum: I retested and PREFIX is broken (it would let you prefix to
> something that isn't a directory but not to a directory). The month is also
> off in timestamps. The next version of GS+ should include the fixes.
>
> In <q4c8ko$ptg$1@dont-email.me> kelvin@pro-kegs.uucp (Kelvin Sherlock) writes:
>
>> ATINIT is only for ProDOS 8. For GS/OS, you need to install the
>> Host.Driver and Host.FST files into your system folder (*:System:Drivers:
>> and *:System:FSTs:, respectively).
>>
>> Under P8, you should be able to PREFIX /HOST. That was originally tested
>> with BASIC and Exerciser.
>>
>> -------
>> ProLine: kelvin@pro-kegs
>
> -------
> ProLine: kelvin@pro-kegs

Thanks.

1. Am I supposed to be able to access the Prodos 8 /HOST in Basic.System launched from GS/OS 6.04? I put the ATinit file in my root folder on the OS disk. I can only access /HOST from a separate Prodos 8 boot disk. I would love to be able to access it from my (childhood) Applesoft Basic scripts launched from the GS/OS desktop. That would allow me to use this /HOST file system to host this code as well.

2. What Marco posted above appeared to say that only the ATinit file was need under GS/OS as well. I am not familiar with how/purpose of Prodos MLI calls. It sounded like there was a different hook mechanism here. (Other than using a native GS/OS driver and FST.) Appletalk file sharing works under both GS/OS and Prodos 8. There was some confusion above about the atinit file being used for Appletalk. You see were I am going with this. Just asking ;). It would be ironic if all of this HST reverse engineering work was done if there was another way to do this.


Thanks again for the work here. I am sure many of us have all had custom KEGS builds/dev going on for years. I'll try to get you some patches in the future to help out.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: VidHD display issues
Next Topic: "Ultimate" Apple //gs disk image?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 07:47:14 EDT 2024

Total time taken to generate the page: 0.06263 seconds