getenv() does not work for ACCs

[th-otto]

The startup code for ACCs does not set up the environment array, thus getenv() does not work for them. This can cause some kind of trouble with ACCs like COPS that try to locate their configuration in $HOME: when run as accessory, $HOME is not found, and the configuration is read from the current directory (which can be anything if ACCPATH is set in xaaes.cnf). When renaming the same program to app and running it from the desktop, $HOME will be used instead.

I currently have no simple idea how to solve this. For apps, the environment array is allocated at the bottom of the heap. For ACCs, where memory management is different, this might be not feasible as the heap is also used for the stack.

[mikrosk]

Does it work in other compilers? (Pure-C most importantly, as this is where COPS comes from)

[th-otto]

I have to check, but Pure-C has completely different startup code of course. IIRC, it did work. Its just a bit difficult to setup an environment for automatic builds using PureC (although not impossible, i've done that already for MagicX).

Just another reason to move cops out of the freemint repo, it is a standalone app that does not depend on any kernel things.

[mikrosk]

Peter Persson has made a nice GEMDOS/CPU emulator for exactly this purpose (building using Pure-C, LatticeC etc). I'll send him this link to comment.

Trouble with moving COPS (and possibly HypView) is, among other things, that I would like to do it cleanly, i.e. transfer it with whole history into a separate repository and delete all traces in the freemint repo => changing history and breaking everyone's fork again.

[shoggoth77]

Basically I made this thing I call "crosstos", which is more or less a cross-compiler-compiler. I also made this .PRJ->makefile conversion script and I've used it to successfully build a couple of PureC projects on my un*x machine. It doesn't do environment variables etc very well yet, and it doesn't take PC.CFG or TC.CFG into account, which means some very minor tweaks to the .PRJ-file may be required (IIRC you need to add system/library paths/includes manually to the .PRJ file).

The project is rather crude and it wasn't intended for a major audience, but if there's interest I could put it public somewhere. GGN/KÜA has used it in Brownbot (for which I can't find a working link atm(?)).

EDIT: Insane/tscc, who unlike myself actually can code, has a similar and somewhat more sophisticated project, but I can't seem to find it atm.

(Shoggoth77 == Peter Persson)

[mikrosk]

Here's the link: https://bitbucket.org/pep-entral/crosstos/src/master/

[shoggoth77]

Just a quick comment; I added lots of compilers, not all of them are useful at this stage. IIRC PC, TC, LC and Devpac/gen.ttp should work, but it's all WIP.

[th-otto]

Took a quick look, and had some problems. First off, and invocations of make in the toplevel spitted out a bunch of warnings about redefinitions. I think this is because of dupicate basenames of TOS programs in different directories (wg. WCONVERT.PRG and WCONVERT.TTP, MV.TTP in 2 different directories etc.).

Then, at some point, it complains about not being able to create dist/LC/m68k-atari-tos-lc-wconvert (the directory in your project is dist/lc in lowercase)

[shoggoth77]

Ah! Sloppy of me. Likely easy to fix; I usually build it on macOS or Windows, but I thought I’d made sure it builds on case sensitive file systems too... I’ll have a look. Thanks for trying it. EDIT: Made a few tweaks on a proper file system, seems to work better now. Feel free to try again. ons 1 maj 2019 kl. 16:25 skrev Thorsten Otto <[email protected]>:

…

Took a quick look, and had some problems. First off, and invocations of make in the toplevel spitted out a bunch of warnings about redefinitions. I think this is because of dupicate basenames of TOS programs in different directories (wg. WCONVERT.PRG and WCONVERT.TTP, MV.TTP in 2 different directories etc.). Then, at some point, it complains about not being able to create dist/LC/m68k-atari-tos-lc-wconvert (the directory in your project is dist/lc in lowercase) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABA7ARPLQ6PY24WQCRTRWRDPTGR5BANCNFSM4FYPX4CA> .

[mikrosk]

Insane/tscc, who unlike myself actually can code, has a similar and somewhat more sophisticated project, but I can't seem to find it atm.

It's available as part of his DSP Cross Tools package at https://insane.tscc.de, namely https://insane.tscc.de/files/atari/dspcrossdev.zip

[shoggoth77]

This is probably because I’ve done makefile magic - and I’m the last person on earth who’s qualified to do that. May also be a goofed up commit. I’ll have a look. ons 1 maj 2019 kl. 16:25 skrev Thorsten Otto <[email protected]>:

…

Took a quick look, and had some problems. First off, and invocations of make in the toplevel spitted out a bunch of warnings about redefinitions. I think this is because of dupicate basenames of TOS programs in different directories (wg. WCONVERT.PRG and WCONVERT.TTP, MV.TTP in 2 different directories etc.). Then, at some point, it complains about not being able to create dist/LC/m68k-atari-tos-lc-wconvert (the directory in your project is dist/lc in lowercase) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABA7ARPLQ6PY24WQCRTRWRDPTGR5BANCNFSM4FYPX4CA> .

[th-otto]

@shoggoth77 still reading here? ;)

Just encountered 2 other problems, while trying to support your tools in https://github.com/th-otto/pcmake/

• the path_find_item() function is broken (see Linux/x86 compatibility? th-otto/pcmake#1). For example, when using mintlib headers, there will be a file mintbind.h in the include directory, as well as a mint subdirectory. Now, when trying to do "include <mint/mintbind.h>", the algorithm will scan the include dir, and if it encounters mintbind.h first, considers that as a match for "mint", because only the 4 chars are compared. Subsequent lookup for mint/mintbind.h then fails.

• Passing command lines longer than 126 chars does not work. The commandline is already truncated in main(), and the way the ARGV=binary is set up in the environment, seems to be broken, too (arguments must be terminated by \0, not ' ', and passing the environment to the child does not work, because parent_pd = 0 in cpu_load()). Also, for using ARGV, the length byte in the command line has to be set to 127.

PS.: sorry for reporting that here, but i don't have an account for bitbucket

[shoggoth77]

@th-otto: Still reading here, it seems! I've seen pcmake and think it makes a good replacement for that ugly python script of mine (I do python by means of googling).

Thanks for trying it out! It's a proof of concept as usual; the idea behind it is better than my actual implementation. I suspected ARGV was broken, and path_find_item() is obviously bonkers. I also suspect environment variables aren't handled properly.

I'll have a look. Patches and suggestions are obviously welcome, and if Bitbucket is a problem I don't mind moving things to github if that suits you guys better.

[th-otto]

github would be easier for us i think, although i can't promise that i have time to look at crosstos that much ;)

A quick fix for path_find_item would be easy:

--- a/paths.c
+++ b/paths.c
@@ -84,6 +84,8 @@ static bool path_find_item(char* path, char* item, int count)
                     }
                 }
             }
+            if (de->d_name[i])
+                match = false;
         }
 
         if(match)

But maybe it is also necessary to rewrite the whole stuff to truncate the matching to 8.3 TOS style names, for both names (maybe depending on the Pdomain of the process, if that is tracked somewhere).

Using toupper() is also not quite right. If you ever use non-ascii characters in the filenames, then one of the names will be in atari encoding, the other in the hosts encoding (which is most likely utf-8 on linux, and thus has 2 or more bytes for non-ascii characters).

I've also tried to look after the ARGV issue, but could not get it to work yet.