> Will we be able to point to Amiga directories to load MS files and images such like? If so this is one huge step forward for AOS4.
Yes of course. You can load, edit and print MSWord text files located on your HD like on every other text processor.
> Also like Hans I have to disable the assign in user startup as it inteferes with NetPanzer (with Hans it is SDK) any fix possible?
This is indeed a serious problem, but I don't know a solution for it. I had to stop using paths like bin: or usr:, but I can't do that. The only solution is to disable the assign AND the startup in the user-startup and use "Start_Cygnix.bat" if you want to run Cygnix.
No this doesn't work. I must correct my comment a little bit. The bin: assign is no problem, but the usr: assign. If you are searching for a file in a sub-directory of usr:, only the files of the first assign are found.
Example:
assign USR: disk:foo assign USR: disk:baz add
If you want to open "USR:bin/echo" the file in disk:foo/bin is found, but not the file in disk:baz/bin!
Is it not possible to map accesses to bin, usr, etc. to a seperate directory, instead of using an assign? So that programs would reference them as Cygwin:bin/ Cygwin:usr/ , etc.? Or use assigns like cygbin:, cygusr:, etc. It should be just a matter of mapping to a different path/assign.
If no such solution is possible, then at least you could only make those assigns when the user executes the Start_Cygwin.bat script, instead of directly in the user-startup. This way it would not interfere with other programs, unless you actually start Cygwin.
Yes, with the second solution it'd good to remember the old assigns and restore it at exit. It's not a nice solution but it'd be better than the way it is currently, having to edit the user-startup and reboot each time we want to run Cygnix.
For the mapping solution I meant Cygnix:bin, etc. not Cygwin, this is what happens to you when you use PCs at work for too long... :/
Is it not possible to map accesses to bin, usr, etc. to a seperate directory, instead of using an assign? So that programs would reference them as Cygwin:bin/ Cygwin:usr/ , etc.?
For that you don't even have to change any code (or only very few which has builtin hardcoded paths instead of using the ones from configure), simply (re)configure und (re)build everything with --prefix=/cygnix, just like it was done in GeekGadgets (there it was --prefix=/gg or --prefix=/ade instead).
> Is it not possible to map accesses to bin, usr, etc. to a seperate directory, instead of using an assign? So that programs would reference them as Cygwin:bin/ Cygwin:usr/ , etc.? Or use assigns like cygbin:, cygusr:, etc. It should be just a matter of mapping to a different path/assign.
Yes, this is possible. It was a mistake I've done when I started with the X-Server. The Cygnix concept was created later. To solve this, I have to reconfigure all libs and projects with an other prefix and recompile everything just like joerg said. But this is too much for me at the moment. It is not a simple recompile - I have over 200 libs and programs here.
BTW: GeekGadgets also uses a usr: and a etc: assign. There was GG:, but it was not always used.
> If no such solution is possible, then at least you could only make those assigns when the user executes the Start_Cygwin.bat script, instead of directly in the user-startup. This way it would not interfere with other programs, unless you actually start Cygwin.
Start_Cygnix.bat does this already. You can use this script without the user-startup stuff. But the assigns and paths are not removed, when Cygnix is stopped and the search paths (path command) are not global then.
Yes, this is possible. It was a mistake I've done when I started with the X-Server. The Cygnix concept was created later. To solve this, I have to reconfigure all libs and projects with an other prefix and recompile everything just like joerg said. But this is too much for me at the moment. It is not a simple recompile - I have over 200 libs and programs here.
I get the idea. But please keep it in the todo list, because currently X11 interferes with a lot of programs, not just the OS4 SDK. For example it took me ages to find out that Quake3 no longer works because of the assigns Cygnix makes.
Quote:
Start_Cygnix.bat does this already. You can use this script without the user-startup stuff. But the assigns and paths are not removed, when Cygnix is stopped and the search paths (path command) are not global then.
Then I would suggest to remove the lines from the install script, which adds those lines to the user-startup, or it'd be even better to make the installer remove it if it finds such in the user-startup from an older Cygnix installation.
I get the idea. But please keep it in the todo list, because currently X11 interferes with a lot of programs, not just the OS4 SDK. For example it took me ages to find out that Quake3 no longer works because of the assigns Cygnix makes.
Never see any problems with X11.
FYI, Quake2 doesn't use any assigns. The original install uses Envarc.
I am using a kludged work around. There was a thread that directed to create a path like this in your games directory where your Quake 3 folder resides
for mine this is: Games:OS4games/cygnix/home/root/.q3a/ make sure you create each of these folders.
In user-startup-I disable the line assign Cygnix: "Work:OS4Apps/X11R6.3-Pre3"
During boot up you will get asked to assign cygnix, just ignore. In the meantime you can play Q3 or Netpanzer but once you start cygnix manually you may have problems, my quake 3 runs but with no sound (obviously it has been handed over to cygnix).