[hatari-devel] Executing program with Hatari (was: [Bug #17567] ...)

Eero Tamminen eerot at users.berlios.de
Wed Oct 6 21:01:26 CEST 2010


Hi,

On Tuesday 05 October 2010, Miro Kropacek wrote:
>> I was thinking that if Hatari could create the INF file virtually, then
>> the program could be in a read-only directory, e.g. on CD.
>
> Yes, this respects my wish of not bothering user with some crappy
> DESKTOP.INF file, as it's created virtually. With this feature, I mark
> this feature request as perfectly done ;) You can do it as following:
> take current emulated GEMDOS HDD, look for desktop.inf/newdesk.inf, if
> present, do nothing (or make it optional, what to do). If not present,
> look for command line argument if there isn't something to run, if so,
> create virtual inf file and slide it to GEMDOS HDD. Shouldn't be so hard
> or?
>
>> Hatari package for Linux distros could then even register a Linux
>> binfmt_misc handler that invokes Hatari automatically

Here's documentation on binfmt_misc:
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/binfmt_misc.txt;hb=HEAD

The annoying thing about it is that user needs to have it enabled in
kernel and to have this setting persistent, it needs to be registered in
boot (Debian has binfmt-support package to help in that, but then
user needs that package to be installed).

Attached is a script to do that.  You need to run it as root or add it
to your distro's init scripts.

Good thing is that then you can then run the Atari programs directly,
hatari-tosrun.sh will be invoked directly.


>> when one clicks on an Atari binary.

But to have it working just on Desktop and its file manager, Hatari package
done by distro maintainers could just register the hatari-tosrun script as
mime-type handler for *.TOS/TTP/PRG/GTP files.

You could file a bug about that to your favorite Linux distro once I've
added something like described below to Hatari...


>> (Like some people have done with Wine and Window 
> > programs or Java VM and Java programs.)
>
> Holy crap, this would be awesome !!!

And easy to do.  :-)

Only problem is that it needs the program directory to be writable...


One possibility would be to in Hatari start:
* Check if the given file is a GEMDOS program (starts with 0x601a)
  instead of disk image.  If it is:
  - enable GEMDOS HDD emulation for directory where this program resides
  - write a suitably modified desktop file contents e.g. into  ~/.hatari/
    directory.  Contents will be different depending on whether
    normal TOS or EmuTOS is used
  - set a flag that DESKTOP.INF/EMUDESK.INF file opens should be
    redirected in GEMDOS emulation to this file (maybe only first one
    after boot?)

Thomas, Nicolas, how does that sound?  Acceptable? :-)


> > This isn't that critical. Can be added later, if needed at all.
> >
> > It might be nice for the cases when the messages disappear too fast to
> > read them.  Unfortunately it seems that e.g. EmuTOS messages cannot be
> > catched this way[1].
>
> I meant, this particular feature of re-interpreting escape codes isn't
> that critical, the feature as whole is something I miss badly ;-) I don't
> care about OS stuff (one can use much better techniques provided by
> excellent Hatari debugger), this is about application level, it's so
> boring to implement "press a key to exit" for TOS programs, prey text
> will fit into console size and wont scroll away etc... (esp. for demos
> where graphics, i.e. non-console screen is used I have no other options
> for logs than postponed screen output of files, what is quite
> inconvenient).

Ok, sounds useful.  I'll start looking into that...

I think for starters it's enough to have just a command line debug option
(that's valid only when HD emulation is in use as otherwise GEMDOS
isn't redirected[1]), appropriate GEMDOS function redirection and
internal flag about this[1].

[1] As this is a debug flag, I don't think it needs to be something that's
stored into Hatari config file.


	- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tos-register.sh
Type: application/x-shellscript
Size: 1261 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20101006/c05cdf2f/attachment.bin>


More information about the hatari-devel mailing list