again MeShell - binary distinguishing PM programs from cmd programs

[Martin Vieregg]

I have written a syntax completion of commands for the next MeShell version. For this purpose, I have saved the PATH list exe, com, bat and cmd files in a very fast string list. I want to use this for another purpose:

In my opinion, it is nervy to write "start" in front of the name of the PM program which is not running in the same session as cmd.exe. Otherwise MeShell switches to non prompt state (LED glows red). I want to send a "start progname" to cmd.exe instead of "progname". I need a secure way to binary analyze the EXE file and to see if it is a PM program or a cmd program (generating stdout or VIO and running in a command window). Any ideas what part of the binary I have to check? Or is there an API call doing this?

[Pete]

Hi Martin

You probably want to play with DosQueryAppType


Regards

Pete

[Dave Yeo]

IIRC, it is a bit in the executables header. There's other ones to consider like a program that can only run in a full screen session, which would also need start or start /f, plus it is possible to morph a vio program into a PM program.
exehdr.exe /? gives these options,

/PMTYPE:(PM | VIO | NOVIO | WINDOWAPI | WINDOWCOMPAT | NOTWINDOWCOMPAT

[Martin Vieregg]

Thank you for your answers. DosQueryAppType should fit my purpose. This API call refers to the bits Dave mentioned. I assume that the following bits are interesting for me:

001 -     (FAPPTYP_NOTWINDOWCOMPAT, 0x00000001): Application type is not-window-compatible.
010 -     (FAPPTYP_WINDOWCOMPAT, 0x00000002): Application type is window-compatible.
011 -     (FAPPTYP_WINDOWAPI, 0x00000003): Application type is window-API

So it seems that 0x1 means the program runs in the cmd.exe session.

Bit 5     (FAPPTYP_DOS, 0x00000020): Set to 1 if the executable file is in PC/DOS format. Bits 0, 1, 2, 3, and 4 will be set to 0.

DOS programs have to run in their own session, of course. So I think simply checking bit 0x1 set and 0x2 unchecked should be sufficient.

I will report here after testing different sample programs. I am not clear what "window-compatible" means.

[Lars]

"window compatible" is a text mode application that can run either in a command window or fullscreen.
"not window compatible" is a text mode application that can only run fullscreen.
There are only a few text mode applications that have a technical reason to run "only fullscreen" but by setting the corresponding bit (via MARKEXE.EXE or by setting the corresponding linker DEF directive) you can force the system to only allow that app to run fullscreen.

[Martin Vieregg]

OK. Then "window-compatible" is the only case where I do not need the START command, because fullscreen needs an own session.

Is there a case where this automatic behaviour should be omitted? (Is a user setting for this option necessary?)

[Andreas Schnellbacher]

Yes, when the app should be started synchronously.

[Martin Vieregg]

What about a leading special character like @ to omit the "start" functionatliy with a separate session? cmd.exe seems to ignore a leading @. Or does it have another meaning?

For example writing a cmd file where a text file is generated, then an editor is started to edit the textfile and then the batch file continues after saving the file and leaving the editor, indeed a possibility to turn off this functionality will be necessary.

[Neil Waldhauer]

In cmd, the @ suppresses echo on the command line.

Code: [Select]

rem without @
dir config.sys
rem with @
@dir config.sys

[Andreas Schnellbacher]

In my opinion, it is nervy to write "start" in front of the name of the PM program which is not running in the same session as cmd.exe. Otherwise MeShell switches to non prompt state (LED glows red).

Without 'start', you start an app synchronously. It's 'call' which you can omit. PM apps may behave different, but with 'start' you go sure that the app is started asynchronously.

As an example: ibmview.exe always starts asynchronously. There you don't need to specify 'start' in the command line. newview.exe needs the 'start', because otherwise it starts synchronously.

The text editor example for a synchronous start is correct. E.g. svn calls  a text editor on 'svn ci ...' to add a message. After saving the file and closing the window, control goes back to the waiting process with svn. BTW: E.g. 'tedit' and 'epm /m' can be used for this.

[Martin Vieregg]

Thank you for the useful hints. @ is not a good idea. Now I realized that "start" and "call" are opposing pairs. So I will add a user setting
[ ] run PM apps asynchronously (via "start")

I assume that PM programs who start asynchronously accept using "start" in front of the program name. IBMview does.
If a user wants to start a PM program synchronously, he has to explicit use "call" in front of the program name if the setting is activated. I will note this in the docu.

In the Windows command line, this is default behaviour.

If a PM program is executed via CMD file, then the setting has no effect, because MeShell does not interpretate the content of the cmd file.