gemma.app doesn't support POSIX paths in SLBPATH

[vinriviere]

I noticed that gemma.app doesn't support POSIX paths in SLBPATH.
While this is supposed to be allowed by the FreeMiNT kernel:
https://github.com/freemint/freemint/blob/dae5f4e6324566deeb2a47bd228ccbc9f3d512e4/doc/examples/mint.cnf#L308-L314

More precisely, I noticed that the gemma programs don't behave identically.

• test.app always works
• gemma.app works when run from TosWin2, but not when run from a TeraDesk window (e:\ for example).

Cause is the format of the SLBPATH variable.
If I set it to /c/mint/slb then gemma.app doesn't run from e:\.
If I set it to u:/c/mint/slb then it works.

Why test.app and gemma.app behave differently?

• test.app only uses Slbopen() to open gemma32.slb, and it works in any case.

• gemma.app first uses Slbopen() to open gemma32.slb, and it also works. Then, for whatever reason, it wants to reopen gemma32.slb. To do that, it uses dos_fsearch():
  

  gemma/configtool/main.c

  Line 97 in 729c078

  r = dos_fsearch("gemma32.slb", fullname, "SLBPATH=");

That dos_fsearch() is implemented in gemma32.slb itself (!).

gemma/src/dosproto.c

Lines 390 to 412 in 729c078

	long dos_fsearch(PROC_ARRAY *proc, const char *name, char *fullname, const char *pathvar)
	{
	const char *path;
	char *end;
	path = dos_getenv(proc, pathvar == NULL ? "PATH=" : pathvar);
	if (path == NULL)
	return -ESRCH;
	while (*path != '\0')
	{
	end = fullname;
	while (*path != '\0' && *path != ',' && *path != ';')
	*end++ = *path++;
	*end = '\0';
	if (*path != '\0')
	path++;
	strcat(fullname, "/");
	strcat(fullname, name);
	if (dos_fsize(proc, fullname) >= 0)
	return 0;
	}
	return -ESRCH;
	}

We can see that it uses dos_fsize(), implemented in the same file:

gemma/src/dosproto.c

Lines 361 to 381 in 729c078

	long dos_fsize(PROC_ARRAY *proc, const char *name)
	{
	struct stat st;
	struct xattr xattr;
	_DTA *olddta;
	_DTA dta;
	long ret;
	UNUSED(proc);
	if (Fstat64(0, name, &st) == 0)
	return st.st_size;
	if (Fxattr(0, name, &xattr) == 0)
	return xattr.st_size;
	olddta = Fgetdta();
	Fsetdta(&dta);
	ret = Fsfirst(name, 0);
	Fsetdta(olddta);
	if (ret == 0)
	return dta.dta_size;
	return ret;
	}

It tries the Fstat64/Fxattr/Fsfirst methods, but none of them seems to be able to deal with POSIX paths.

Finally, gemma.app fails loading with a GEM alert.

[vinriviere]

I must admit that I'm not a big fan of POSIX paths in the SLBPATH. Of course we could fix gemma's dos_fsize() to work on POSIX paths. But it would be simpler (and IMHO more sane) to stick to TOS paths in SLBPATH.

However, SLBPATH and POSIX paths are advertised at several places in the FreeMiNT documentation, so it seems that at some point, some efforts have been made into that direction. Anyway, non-POSIX programs should be able to use SLB libraries without trouble. Finding a POSIX path in SLBPATH or any other variable isn't really expected by non-MiNTLib programs.

[mikrosk]

Anyway, non-POSIX programs should be able to use SLB libraries without trouble

The question here is: who is the target audience for SLBPATH variable? I've always understood it as a kernel setting. If some user (!) application is messing with it, it should be really ready for anything, its format can change any time.

[th-otto]

Then, for whatever reason, it wants to reopen gemma32.slb. To do that, it uses dos_fsearch():

That second open is not done to execute code. It is done to locate the settings structure compiled into the library by searching for the magic 0xdeadefeb.

[vinriviere]

Anyway, as a gemma user, I just want to be able to run gemma.app from TeraDesk in e:\ drive (like test.app). Whatever solution will be fine, as long as it works.