input/output file handles and wb startup

[meynaf]

Hi all,

I'm in the process of adding complete wb startup support for all my programs so i need to be cautious.

Here it's about input/output file handles normal cli processes all have : if run from wb i see null value for both.
If would however be handly for me to be able to continue using things such as PutStr directly. Would remove lots of special cases.

Can i just open a console window and set them ? Any particular precaution to take ?
(Most notably : is same handle allowed for both, must i restore anything upon exit and if so, is simple clearing ok to do.)

In addition if i open a console window, is there a simple and clean way to duplicate the "output window" wb opens by itself when running a program from a pseudo-icon ?
(Instead of using hard-coded values.)

[Thomas Richter]

Originally Posted by meynaf

If would however be handly for me to be able to continue using things such as PutStr directly. Would remove lots of special cases.

The typical approach is to allow a WINDOW tooltype, and the application opens that as stream when run from workbench. If the tooltype is not present, some kind of default is used. Typically, these windows use AUTO/CLOSE/WAIT modifiers such that the console only opens if something is printed, and stays present even after the program exits, so the user can continue to read.

Originally Posted by meynaf

Can i just open a console window and set them ? Any particular precaution to take ?

Only that you should only close the streams if you also opened them, and do not accidentially close the stream the shell provided.

Originally Posted by meynaf

Most notably : is same handle allowed for both, must i restore anything upon exit and if so, is simple clearing ok to do.

The same is allowed for both. System/Execute have some limitations on this, but not regular processes. Actually, the two handlers are just.. two handles that are used by some dos.library functions, e.g. Printf() uses the output handle, and ReadArgs() uses the input handle, though the latter is not very useful for wb started programs.


Again, just be careful to only close what you opened. The workbench does not care about the handles there, it neither touches them, so in principle, dangling pointers in there are allowed - but I'd still call this "bad style". Clean up after you.

Originally Posted by meynaf

In addition if i open a console window, is there a simple and clean way to duplicate the "output window" wb opens by itself when running a program from a pseudo-icon ?

CLICon/IconX is just a regular program that does nothing fancy, it just opens a window from the WINDOW tool type and creates a shell and then runs your program from that shell. It's not that the workbench does anything magic or fancy there.



Thus, that is the very same thing you get when your program is run from an "interactive" shell, no difference.


If you want to open a stream in both cases, one possibility is to open "*" in the shell startup instead of the workbench startup, but this always gives you the console, and not the output file handle (i.e. there will be a difference if your output has been redirected). There is unfortunately no generally valid way how to "clone" a file handle, only for interactive handles (such as the console, SER: or AUX:



A generally nice way to have a unique startup code is to create from the tool types array arguments and create a ReadArgs structure from them, then pass the same thing into the shell startup. This way, you don't have to write two argument parsers. (This is one of the unorthonogalities of AmigaOs I consider an issue of bad design, i.e. such a function should be somewhere in the Os rather than having to rewrite it every time again).

[meynaf]

Originally Posted by Thomas Richter

The typical approach is to allow a WINDOW tooltype, and the application opens that as stream when run from workbench. If the tooltype is not present, some kind of default is used. Typically, these windows use AUTO/CLOSE/WAIT modifiers such that the console only opens if something is printed, and stays present even after the program exits, so the user can continue to read.

Sure, but it's that "some kind of default" that looks problematic.
Workbench won't automatically parse that tooltype and open the console window with safe default values, especially the title bar using the system's locale.

Originally Posted by Thomas Richter

Only that you should only close the streams if you also opened them, and do not accidentially close the stream the shell provided.

Well, in that case there is no shell so i can't close anything - both handles are null. If not run from WB i have no need to touch them.

Originally Posted by Thomas Richter

The same is allowed for both. System/Execute have some limitations on this, but not regular processes. Actually, the two handlers are just.. two handles that are used by some dos.library functions, e.g. Printf() uses the output handle, and ReadArgs() uses the input handle, though the latter is not very useful for wb started programs.

That's some relief. Thanks.

Originally Posted by Thomas Richter

Again, just be careful to only close what you opened. The workbench does not care about the handles there, it neither touches them, so in principle, dangling pointers in there are allowed - but I'd still call this "bad style". Clean up after you.

I have internal resource tracking in my code, so cleanup is hardly a problem

Originally Posted by Thomas Richter

CLICon/IconX is just a regular program that does nothing fancy, it just opens a window from the WINDOW tool type and creates a shell and then runs your program from that shell. It's not that the workbench does anything magic or fancy there.

Thus, that is the very same thing you get when your program is run from an "interactive" shell, no difference.

Right but IconX does not mimic WB's Output Window. Neither can I, apparently.

Originally Posted by Thomas Richter

If you want to open a stream in both cases, one possibility is to open "*" in the shell startup instead of the workbench startup, but this always gives you the console, and not the output file handle (i.e. there will be a difference if your output has been redirected). There is unfortunately no generally valid way how to "clone" a file handle, only for interactive handles (such as the console, SER: or AUX:

It's wb's console window appearance i need to clone, not a file handle.
Opening "*" is of no use - if run from cli i already have everything at hand, and from WB it doesn't work (gives a valid handle but output goes nowhere).

Originally Posted by Thomas Richter

A generally nice way to have a unique startup code is to create from the tool types array arguments and create a ReadArgs structure from them, then pass the same thing into the shell startup. This way, you don't have to write two argument parsers. (This is one of the unorthonogalities of AmigaOs I consider an issue of bad design, i.e. such a function should be somewhere in the Os rather than having to rewrite it every time again).

This is what i've done. I create a string from tool types (also from selected files) and then call ReadArgs with non-zero RDArgs parameter.
ReadArgs is great, tooltypes are great, but we really lack a unified scheme...

[Thomas Richter]

Originally Posted by meynaf

Sure, but it's that "some kind of default" that looks problematic.
Workbench won't automatically parse that tooltype and open the console window with safe default values, especially the title bar using the system's locale.

Correct, the workbench does not care about this tool type, and it neither provides a default for it.



Strangely, there is a field do_ToolWindow in the disk object (see workbench/icon.h), which is read and written by the icon.library as a 0-terminated string, but the workbench provides no means to edit it and neither populates or uses it. Thus, potentially, there was quite a long way ago a plan to provide something like this, but the idea apparently got lost.

[a4k-oerx]

Originally Posted by Thomas Richter

Strangely, there is a field do_ToolWindow in the disk object (see workbench/icon.h), ... Thus, potentially, there was quite a long way ago a plan to provide something like this, but the idea apparently got lost.

AMIGA Datenstrukturen - Lexikon. Das Nachschlagewerk für alle Programmierer | Lukowicz, Paul, Pfeiffer, Olaf | ISBN: 9783890902500 | archive.org

Originally Posted by AMIGA Datenstrukturen - Lexikon, page 273

do_ToolWindow 0x0046 (70) - Ein Adreßzeiger auf eine C-Zeichenkette, die ein CON:- oder RAW:-Fenster beschreibt, das beim Start des zu diesem Icon gehörigen Programms als Standardein-/Ausgabedatei geöffnet werden soll. Der Adreßzeiger auf die Window-Datenstruktur (siehe »Intuition«) des neuen Fensters wird dabei automatisch in die Komponente pr_WindowPtr der Process-Datenstruktur (siehe »Dos«) des Programms eingetragen. Um kein Fenster automatisch öffnen zu lassen, trägt man hier den Wert NULL ein. Dieser Adreßzeiger ist nur für Icons vom Typ WBTOOL von Bedeutung.

Sorry for german quote, the book is written in german, feel free to do a full translation.

It basically says, the field contains a pointer to a string with a CON:/RAW: window definition which should be used for standard in/output of the program and the window pointer will be written to some other structures automatically.

Edit: Some further research shows, that Directory Opus 5 obviously respected do_ToolWindow also with other values than NULL, file dopus5allamigas/source/Library/wb.c:1639 at github.com

// Tool window?
if (icon->do_ToolWindow &&
	(copy->doc_DiskObject.do_ToolWindow = L_AllocMemH(data->memory, strlen(icon->do_ToolWindow) + 1)))
	strcpy(copy->doc_DiskObject.do_ToolWindow, icon->do_ToolWindow);

[Thomas Richter]

What you see there in the German manual is just a direct copy/translation of what the RKRMs 1st edition stated about the field, literally. The 3rd edition just states (correctly) that this field is "reserved for future use". Actually, it was never used and was always reserved.

What DOpus does here is pretty much the same what the icon.library does: It carries the field around, but it doesn't touch or interpret it. Even the llatest icon.library copies the data, and the data is also part of the .info file and will be written and read back from disk. Just that it's of no particular use, and cannot be set from the user.

[a4k-oerx]

My RKRMs 1st edition actually state something different (did not even bother to look there first), main difference marked in quote.

do_ToolWindow
By default, Workbench will start a program without a window. If ToolWindow is set, this file will be opened and made the standard input and output of the program. This window will also be put into the process's pr_WindowPtr variable and will be used for all system requesters. Note that this work is actually done in the language-dependent startup script; if you are coding in assembly or an unsupported language, you will have to do the work yourself. The only two files that it makes sense to open are "CON:" or "RAW:". See the AmigaDOS manual for the full syntax that these devices accept.

The quote in AMIGA Datenstrukturen - Lexikon says, pointers are set automatically - without any note about language etc.

So I guess nothing besides the field in structure was implemented at any time on OS side. On the other hand, especially with Amiga you never know, what has actually been done but later dropped due to ROM space or similar etc. or if/where this "startup script" was actually available or wasn't