Tcl Source Code

Windows GUI applications are detached from a console 
and do not support pipes.  [exec] should know this.

Here's what I added:
C:\WINNT\system32>tclsh84
% exec notepad
C:\WINNT\system32\notepad.exe is a GUI application 
that doesn't support pipes: broken pipe
% puts $errorCode
POSIX EPIPE {broken pipe}
%

I feel the errorCode is conceptually correct.  I also 
added deeper checks into the PE header of the file for 
checking if the file truly is executable.  I also 
added a check for the .cmd extension which is 
analogous to .bat

The best way to launch GUI applications is with 
ShellExecute() rather than CreateProcess().  [exec] 
can not support pipes to GUI applications and i feel 
it should be disabled.  This would of course need a 
new command for launching GUI apps...

Logged In: YES 
user_id=72656

This may also have something to do with Tk bug 232731 
(exec grabs stdin -- wish on Win9x only).

Logged In: YES 
user_id=75003

I have no trouble with a better PE reader.
Increased robustness is good.

Given your example below, will change the win/exec to make 
use of these pipes ? Or do they already. I guess not.

Logged In: YES 
user_id=7549

Looks like pipes to GUI apps is valid:

STARTUPINFO si;

int WINAPI
WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR 
lpCmdLine, int nCmdShow)
{
    GetStartupInfo(&si);
    return 0;
}

si.hStdOut is valid when launched with [exec]!!  WOW, I'm 
in shock.  A detached console, but who cares, pipes work!  
Amazing...

Now I forgot what I was trying to fix...
so it goes...  Anyone want a better PE reader, but for no 
useful purpose?

Logged In: YES 
user_id=7549

I think I got different builds confused from one another...
Still studying...

Logged In: YES 
user_id=7549

I hear you, but I strive for perfection :)

An interesting behavior I just discovered.  When embedding 
Tcl into a GUI app, [exec]'d console apps are visible.  Due 
to the redirection the console window is blank, though.  
Wish does not exibit this behavior.

I'll be studying this for the next few days.  I feel 
redirected apps should not have a blank and visible console 
with it.  aotto on c.l.t was mentioning this behavior, but 
I don't see it with wish, just embedded apps.

To me, redirection means no visible components wanted.  I 
wonder why wish is not the same as my Tcl'd IRC client?  
Or, why are redirected console apps visible from my GUI app 
that embeds Tcl?  Very interesting...

Logged In: YES 
user_id=79902

IIRC from my DOS days, COM files have no internal signature
and are just raw code. If that's right, it wouldn't surprise
me in the slightest if there's probably not much we can do
about bad COM files.

If it looks difficult to achieve perfection, try for the
next best thing...  :^)

File Deleted - 16064: 



File Added - 16070: diff.txt

Logged In: YES 
user_id=7549

improved the patch and fixed a couple bugs introduced from 
before.  All spots that return APPL_NONE now set a useful 
errorcode.  Bad .com programs still cause a system dialog 
to popup.  I don't see a way to bypass it.

File Added - 16064: diff.txt

Logged In: YES 
user_id=7549

Here's what I have so far.  The prototype for 
ApplicationType took some changes.  I dropped the 
Tcl_Interp* because it can be done in TclpCreateProcess(), 
and changed fullName to be a Tcl_DString so it can manage 
the buffer size.  Filename prepended with "//?/" can have 
lengths greater than MAX_PATH.

I haven't run the test suite yet.  Batchfiles used to 
return APPL_DOS, but now return APPL_BATCH.  batchfiles 
aren't DOS.  They'll need the command processor, but that 
isn't DOS (per se) either.

Logged In: YES 
user_id=75003

Adding the launch and shell commands to the core, or even 
only bundling the extension with the core will require a 
TIP. My personal preference is always to have a separate 
extension first.

The rerouting to a TclpCreateProcess which doesn't do Pipes 
might/could work. But also makes the Tcl internals more 
complex. Does TclpCreateProcess take flags ? This might be 
better, no additional function, just extending the existing 
one.

Ok, my current state here is: Apply the parts of the patch 
changing and extending the PE detection, leave out the 
block of GUI apps in [exec]. A TclpCreateProcess with a 
flags argument (if none yet), or extended flags can be done 
in a separate patch (Which could refer to this one for 
documentation purposes).

Logged In: YES 
user_id=7549

We could add my launch and shell commands to the core (?)

Just a thought, so people wouldn't need to go search for 
yet another extension.  I understand your reasoning for 
keeping it, but I'm so tempted to block [exec] from 
launching GUI apps :)

What if in the PE detector [ApplicationType()] when it 
determined it was a GUI application it was re-routed to an 
alternate TclpCreateProcess() that didn't bother with pipes?

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\WINNT\system32>tclsh84
% set chan [open "|notepad" w+]
file8f6860
% fconfigure $chan -blocking no
% fileevent $chan readable [list gotStuff $chan]

I look at the above and it makes me sick...
It should toss an error.

Logged In: YES 
user_id=75003

My thanks for your explanations and references.

I still convinced that we should not stop exec on Windows 
from running GUI applications. Why ? My reasoning is this:

Most people have the simple need of just wanting to start 
an external application, GUI or not, without fuss, without 
frills. And [exec] is the cross-platform way to do so. Only 
if they want to do all these special windows things 
like 'start mininized' etc. [exec] is outclassed. At that 
point we can then tell them "what you eant to do specific 
to Win* and there (insert url) is the extension to 
accomodating your needs".

I believe that what you are doing is basically breaking a 
case which is handled correctly by Tcl, at least from the 
view of the majority of people using it on windows to 
essentially force them to use a special extension only few 
have a true need for.

Logged In: YES 
user_id=7549

Here's something I've been working on toward an addition 
that's optimized for windows without the posix blinders:

http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/*checkout*/tomasoft/winutils/winutils.html?
rev=1.3#launch

Logged In: YES 
user_id=7549

[exec] is designed to hook-up to pipes and return what the 
app pipes out.  GUI apps just don't support pipes as the OS 
loader will detach them.

Yes, you can start a GUI app with [exec], but why?  None of 
the windows specific options are supported such as "start 
minimized", "default thread priority", "run associated app" 
and such.  Windows is not posix and only character-mode 
applications do pipes.  Therefore, anyone expecting a way 
to launch the default web browser and wants [exec] to do it 
falsely assuming [exec] is the capable way to do it without 
extra command prompts flashing up momentarily on the screen 
when commandlines like this are used as a shabby hack from 
wish:

eval exec [auto_execok start] stuff.html

Logged In: YES 
user_id=75003

I have to admit that I do not like the part changing the 
behaviour of [exec]. I mean, if I do [exec notepad] right 
now, with or without & the system behaves as expected. I.e. 
it launches notepad, possibly in the background. No crash, 
no error message on the tcl level. What is the problem 
solved by this change in behaviour ?

Logged In: YES 
user_id=7549

>Is it possible to extend the testsuite with existing 
helper 
>executables which can be [exec]uted ?

Sure..  I don't the tools to make them though.

PharLap sets some different header fields in the exe.  I 
think it uses 'NE' and sets the PM flag, but I'm not sure.

Actually, I'm not sure of a great many things with this.  
There are quite a number of different uses of the old 'MZ' 
header and the newer style, that I can't be sure of much 
except from the docs I read that helped me understand (get 
all confused) about reading an exe header for the info it 
has about the executable.

To verify a great many styles of headers we'll either need 
the tools to create these MS-DOS,OS/2 odd-balls, or assume 
the header reader I made is working as is.

NOTE: OS/2 is a subsystem on NT and running OS/2 apps are 
supported.  OS/2 Warp might not be..  very unsure..

Logged In: YES 
user_id=75003

Is it possible to extend the testsuite with existing helper 
executables which can be [exec]uted ?

Why is a pharlap dos extender required ?

Logged In: YES 
user_id=7549

NOTE: the LE, LX, and W3 code paths haven't been checked 
yet.  (no worthy compiler here).  Nor have I found an NE 
DOS exe.  The os/2 one i found worked fine.

If I should put together a test suite, it'll need some odd-
ball compilers to pull it off.  Turbo Pascal for DOS...  
PharLap DOS extender...  character mode emm386 apps?  Is 
there such a beast?

File Deleted - 11778: 



File Added - 11789: noGUIexec.txt

Logged In: YES 
user_id=7549

I'm more satisfied with this patch as it covers more types.

File Added - 11778: noGUIexec.txt