|Re: [hatari-devel] A question about the debugger|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
(I'll look at the other issues you mentioned later,
I just wanted to answer this first.)
On tiistai 15 syyskuu 2015, Roger Burrows wrote:
> Another follow-up ...
> On 14 Sep 2015 at 22:58, Roger Burrows wrote:
> > At this point, the only thing left to try is to make the GEMDOS drive
> > the 'C' drive, and try autostart. I'll do that next. I'm probably
> > being very stupid about this, but I don't find the debugger very easy
> > to use, at least under Windows ...
Hatari developers don't have/use Windows, and as your issues are
new to us, I guess you're unfortunately spearheading the debugger
logging usage there...
> Well, I fought my way past the discovery that the path specified for the
> autostart program overrides the GEMDOS drive specified in the
It has to. Autostarting is implemented by providing an autogenerated
DESKTOP.INF (or EMUDESK.INF) file which tells TOS to start
Hatari has no way to guess what path depth you want, so it just
assumes that program works fine when GEMDOS drive is pointed
at the autostarted program directory. 99% of them do work fine.
> But I still can't get autostart to work. The message
> from Hatari is: "Failed to create autostart file for 'PULSE.PRG'."
> What does that mean?
Windows crappiness. The standard C tmpfile() function doesn't
return on your system a writable file / name.
According to MSDN, this seems to require root dir to be writable:
Btw. That same page recommends using tmpnam() or tempnam()
if one wants version that creates the temporary file
somewhere else, but Linux documentation states on those:
"POSIX.1-2008 marks this function as obsolete.
Never use this function. Use mkstemp(3) or tmpfile(3) instead."
However, mkstemp() isn't portable (it's POSIX, not ANSI-C function),
so Hatari picked tmpfile().
Ps. This isn't first standard C function where we've found
Windows to be crap (after user complaints).