Re: [MiNT] How program CWD can change during appl_init() call?

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On keskiviikko 09 tammikuu 2013, Helmut Karlowski wrote:
> Eero Tamminen, 09.01.2013 15:33:36:
> > I've wondered about that too, why it needs multiple Return presses.
> > As you can see from the sources, it's just a normal form_alert() call.
...
> > Does the same problem happen if you build test.c with newer
> > GCC/GEMlib/MiNTlib?
> 
> Same with gcc 4.5.2 from Alan and some recent libgem. But only the
> gcc-compiled one, and also when launched by XaAES. The vbcc-version does
> it also when it succeeds (launched by XaAES), so it's the alert itself.
> 
> Guess it's the 0:
> 
>                  if(rsrc_load(RSCFILE)) {
>                          form_alert(1, DLG_RSC_OK);
> 
> This works.

Wow, two bugs with the same small test program.  :-)


> > AFAIK VBCC (libraries) don't have any calls to Dsetpath()
> > and the test program definitely doesn't have them, so
> > these calls are being done on the OS side.
> 
> They are only in the vbcc-version, what does not mean they come from
> the OS.

VBCC uses GEMlib for AES calls.

If you look into GEMlib code, appl_init() doesn't do
any file system calls, and neither does rsrc_load(),
they're just thin wrappers around operation system
calls.

However, rsrc_load() does file system operations inside the OS.
Normal TOS does the following ones:
----
AES call 110 rsrc_load(addrin: "BALLER.RSC")
GEMDOS 0x2F Fgetdta()
GEMDOS 0x1A Fsetdta(0x90a0)
GEMDOS 0x4E Fsfirst("C:\TEST.GEM\BALLER.RSC", 0x7)
GEMDOS 0x4F Fsnext()
GEMDOS 0x1A Fsetdta(0x12578)
GEMDOS 0x3D Fopen("C:\TEST.GEM\BALLER.RSC", read-only)
GEMDOS 0x3F Fread(64, 36, 0x6de2)
GEMDOS 0x48 Malloc(0x3094)
GEMDOS 0x42 Fseek(0, 64, 0)
GEMDOS 0x3F Fread(64, 12436, 0x287a0)
GEMDOS 0x3E Fclose(64)
----
(output is from OS tracing feature I've added to Hatari)


I don't think it impossible that OS would in some case
do also Dsetpath(), if it sets that back before returning.
But I don't see why that would be done in appl_init()... :-)


> Maybe it's something with unixmode from mintlib's startup?

VBCC doesn't use MiNTlib.  Its standard library for Atari
is very basic, except for the SW floating point, it's
just thing wrappers around OS calls.  It's even missing
all the Unix/POSIX stuff like stat(), chdir(), getcwd(),
sleep(), errno etc...

(Because it doesn't implement chdir(), its standard lib
can be completely without Dsetpath() calls.)


> I'll see what happens in XaAES later.

Thanks!


	- Eero