Re: [ jEdit-devel ] [ jedit-Bugs-457071 ] change directory in Console crashes

[<dmo...@gm...>]

On Sunday, September 02, 2001, 5:14:56 PM, John Gellene wrote:
>> > Was this not a problem under the former version of Console=3F
>>
>> Strangely not. Although in former versions, command.com wasn't executed
>> automatically on startup. I can't remember when was the last time I
>> invoked "dir" or "command.com /c dir".

> It would be interesting to know if "command.com /c set" hangs under Conso=
le
> 2.X or Console 3.0.2.

It doesn't crash jEdit or Console, but the process doesn't terminate. I
can kill the thread with the stop button; the command.com process will
be terminated correctly then.

>> > (2) Have you tried running "command.com /K set", then Process.destroy()
>> > after the readline() loop exits=3F
>>
>> The readline() loop doesn't exit. It hangs forever _in_ readline(). See
>> above.
>> [...]
> I saw a number of newsgroup postings referring to the problems in these
> terms.  Two suggestions that worked according to the postings was (1) use
> DataInputStream instaed of BufferedInputStream (ignoring the fact that
> DataInputStream.readLine() is deprecated) and (2) set the buffer size in
> BufferedInputStream to 1.

> I don't think either of these will work.

They don't. I checked.

> As the MSDN article I cited
> yesterday suggests, the problem is the architecture of 16-bit console
> applications (like the command.com built-ins).  The Buffered InputStream =
is
> not getting the final EOF character that will cause an exit from the
> realLine() loop.

> The fix described by Microsoft is to interpose a 32-bit console applicati=
on
> between the parent process and the 16-bit console process.  Maybe there is
> another solution but it's likely to be buried deeply within Windows
> internals.

> The first version of jcmd tried to work around this.  As I mentioned
> earlier, it's not compatible with Console 3.X, so I waited until 3.X beca=
me
> stable.  What I am now attempting is a substitute command interpreter that
> accomplishes the following in a Java environment:

> -eliminates console pop-ups
> -hooks up 16-bit Windows console properly so that read operations from th=
eir
> output are not blocked
> -emulates native command interpreter file searching protocols, including
> file extension completion (which the psuedo-environment in Console 3.X do=
es
> not do correctly)
> -enables file assocations from the command line, so that, for example,
> entering simply "myscript.py" on the Console command line will run the
> Python interpreter if the user has so specified or if this was set up dur=
ing
> Python installation

That sounds great!

> The biggest problem is this:  there is no way to deterimne in advance of
> executing a program whether a application is console based or Windows GUI
> based.  If you call the chile process with a hidden window, it's great if
> the appication uses a console, but it will hide the GUI if there is one.
> Currently jcmd tests for the presence of a console window (or no window at
> all) when it creates the child process.  If it determines from these tests
> that the program is GUI, it closes it with Windows messages (or by killing
> the process if absolutely necssary) and restars the process with windows
> visible.

Is there really no other way=3F!=3F Seems like a brutal hack to me...

>> The ideal solution would be a substitute for Sun's Process class:
>> An external JNI library with an exec() method like this:
>>
>> public class WinProcess /* extends Process =3F!=3F */
>> {
>>        public InputStream getInputStream();
>>        public InputStream getErrorStream();
>>        public OutputStream getOutputStream();
>>        public int getExitCode();
>>        public void waitFor();
>>        public void destroy();
>>
>>        public static native WinProcess exec(String[] args,
>>            String[] env, File currentDir);
>> }
>>
>> Console could load this library if started on Windows. Maybe someone has
>> alread done this=3F
>>
> I spent some time researching yesterday and I did not find it.  Since the
> solution appears to require a Win32 exectuable running in its own process=
, I
> think the sensible development path is first to get an executable that
> works, then wrap it in a class that connects to it using JNI.

You're right.

> The executable could also be ultimately packaged as a COM server
> application (which may have some use outside the jEdit world), but JNI
> access will still require a native executable to invoke the server.

Uh, no, not COM again. We've had already too many problems with the
registration of the jEditLauncher component. Why would anyone want to
reboot the computer just to complete the installation of the Console
plugin=3F Please adhere to the KISS principle.


Dirk.