mabe02 / lanterna

Java library for creating text-based GUIs
GNU Lesser General Public License v3.0
2.3k stars 243 forks source link

javaw.exe required on windows, problems with gradle installDist #593

Open damnms opened 10 months ago

damnms commented 10 months ago

Hi, first of all: thanks for lanterna, i really like that. I have a application that works like a charm on linux. Now i thought i provide also a windows build for it. For that i use gradle and the installDist target which produces a .bat and a .sh with everything required to run the application. Unfortunately, on windows when i doubleclick the .bat, nothing happens. I checked the console and noticed that it references the #335 bug. When i replace all "java.exe" with "javaw.exe" in the .bat, it works. Is there any plan for lanterna to implement this so it works also on windows with java.exe instead of javaw.exe?

avl42 commented 10 months ago

It's a bit more complicated...

if you want this emulated terminal window, then you indeed need javaw.exe: What part creates the bat file? is it a file in lanterna? what change would it need?

One alternative would be running in a cygwin terminal (with some special tricks to do the stty stuff, as it doesn't work when called from within java)

Another one is compiling lanterna with the JNA parts - with those it would be ok to run with java(no w).exe, and it would open up within the cmd.exe window. This path is (afaik) not well tested yet, as no one dived into that pond yet and supplied feedback.

On Wed, Jan 24, 2024 at 4:33 PM damnms @.***> wrote:

Hi, first of all: thanks for lanterna, i really like that. I have a application that works like a charm on linux. Now i thought i provide also a windows build for it. For that i use gradle and the installDist target which produces a .bat and a .sh with everything required to run the application. Unfortunately, on windows when i doubleclick the .bat, nothing happens. I checked the console and noticed that it references the #335 https://github.com/mabe02/lanterna/issues/335 bug. When i replace all "java.exe" with "javaw.exe" in the .bat, it works. Is there any plan for lanterna to implement this so it works also on windows with java.exe instead of javaw.exe?

— Reply to this email directly, view it on GitHub https://github.com/mabe02/lanterna/issues/593, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDBMQPW5B7JXH5E4NP7GTYQESTLAVCNFSM6AAAAABCI63DCWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4TQNJTGA3DQNI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

damnms commented 10 months ago

gradle´s installDist target creates the distribution with a .bat and a .sh. Its from the official gradle distribution plugin (https://docs.gradle.org/current/userguide/distribution_plugin.html). Relying on something that exists only in windows is, well, not so optimal. There is no javaw in mac nor in linux, only in windows. Right now, i use sed to replace the java.exe command with javaw.exe and it works, but it feels very wrong.

A "normal" windows user clicks on the .bat/.exe and its done. Usually, windows user do not have cygwin installed.

avl42 commented 10 months ago

That raises a question: isn't this a gradle topic rather than a lanterna one?

On Wed, Jan 24, 2024 at 11:24 PM damnms @.***> wrote:

gradle´s installDist target creates the distribution with a .bat and a .sh. Its from the official gradle distribution plugin ( https://docs.gradle.org/current/userguide/distribution_plugin.html). Relying on something that exists only in windows is, well, not so optimal. There is no javaw in mac nor in linux, only in windows. Right now, i use sed to replace the java.exe command with javaw.exe and it works, but it feels very wrong.

A "normal" windows user clicks on the .bat/.exe and its done. Usually, windows user do not have cygwin installed.

— Reply to this email directly, view it on GitHub https://github.com/mabe02/lanterna/issues/593#issuecomment-1909013282, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDBMSXXRCXL6DKL67G4JDYQGC3NAVCNFSM6AAAAABCI63DCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBZGAYTGMRYGI . You are receiving this because you commented.Message ID: @.***>

avl42 commented 10 months ago

oh wait, I might have misunderstood your answer... so gradle writes calls to java.exe in its generated .bat files...

First question: maybe you can tell gradle with some options to write javaw.exe into the bat? Let it know that it's about a GUI application. (I'd be surprised if gradle didn't have a way to specify javaw.exe or java.exe, but I don't really know.)

Second question: Why would javaw.exe not existing on linux/unix/mac even matter here? Afterall, "java.exe" and ".bat"-files aren't on linux/unix/mac, either.

On Thu, Jan 25, 2024 at 12:13 AM Andreas Leitgeb @.***> wrote:

That raises a question: isn't this a gradle topic rather than a lanterna one?

On Wed, Jan 24, 2024 at 11:24 PM damnms @.***> wrote:

gradle´s installDist target creates the distribution with a .bat and a .sh. Its from the official gradle distribution plugin ( https://docs.gradle.org/current/userguide/distribution_plugin.html). Relying on something that exists only in windows is, well, not so optimal. There is no javaw in mac nor in linux, only in windows. Right now, i use sed to replace the java.exe command with javaw.exe and it works, but it feels very wrong.

A "normal" windows user clicks on the .bat/.exe and its done. Usually, windows user do not have cygwin installed.

— Reply to this email directly, view it on GitHub https://github.com/mabe02/lanterna/issues/593#issuecomment-1909013282, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDBMSXXRCXL6DKL67G4JDYQGC3NAVCNFSM6AAAAABCI63DCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBZGAYTGMRYGI . You are receiving this because you commented.Message ID: @.***>

damnms commented 10 months ago

i was also considering to raise a feature request in gradle, but i talked to some guys in #java on libera.chat and they told me, i am so free and cite one which is very very well known (so i trust him when he says do it that way or that way): "person: You'd want a way to ensure a console window, rather than changing the invocation command" and i replied: "the "usual" windows user clicks on the .bat and does not open a terminal and executes it in there". and he responded: "sure. But is there a way for a java process to say "hey, I need a console window, CREATE ONE"? and i replied: "you mean i should check if its windows OS, if so create a console window and execute my application? that feels more wrong than the sed approach :D" and he wrote: "well, I don't think YOU should do it, but lanterna should :)"

i dont want to hack around to produce distributions that are compatible on different platforms. i mean, thats why there is java, isnt it. so for me, as end-user, i want to use lanterna and be able to run that produced artifact on windows, linux and mac, without touching anything else.

Second question: Why would javaw.exe not existing on linux/unix/mac even matter here?

Because you rely (on javaw.exe) software that is not portable and not on other systems, it is only there on windows. If lanterna is a windows only library and it requires javaw, okay. But if should be compatible to linux/mac/*bsd/etc. - then one should only rely on whats on all systems, and that is java. Otherwise, such things happens with now gradle. Guess the same will happen with every distribution tool.

Afterall, "java.exe" and ".bat"-files aren't on linux/unix/mac, either.

Thats wrong. The .bat file is generated on a linux system and the java.exe is java, just in another format. Javaw is something very different. Again: i build my software on linux, it works like a charm on linux, it works on *bsd, mac, etc. - but not on windows, because of javaw. Its like relying on a windows curl .exe instead of the curl library that can be used anywhere.

right now i use sed to replace "java.exe" with "javaw.exe" in the bat file. but thats nasty.

avl42 commented 10 months ago

Seems like you got me wrong a bit.

I mean: ".exe" and ".bat" files are already a "Windows"-thing - who cares, if the exact javaw.exe doesn't exist anywhere else? You wouldn't use the .bat file anywhere else, and (hopefully) you don't do the "sed" on the .sh script, anyway.

The Java guy probably meant to push you towards the JNA-thing, that would ideally make the double-click on .bat to open the "DOS-box" and show the lanterna UI inside that dos-box.

If you don't want to invest any of your time into getting "lanterna for DOS-box" working, then your current "sed"-approach is your only remaining option.

On Thu, Jan 25, 2024 at 9:57 AM damnms @.***> wrote:

i was also considering to raise a feature request in gradle, but i talked to some guys in #java on libera.chat and they told me, i am so free and cite one which is very very well known (so i trust him when he says do it that way or that way): "person: You'd want a way to ensure a console window, rather than changing the invocation command" and i replied: "the "usual" windows user clicks on the .bat and does not open a terminal and executes it in there". and he responded: "sure. But is there a way for a java process to say "hey, I need a console window, CREATE ONE"? and i replied: "you mean i should check if its windows OS, if so create a console window and execute my application? that feels more wrong than the sed approach :D" and he wrote: "well, I don't think YOU should do it, but lanterna should :)"

i dont want to hack around to produce distributions that are compatible on different platforms. i mean, thats why there is java, isnt it. so for me, as end-user, i want to use lanterna and be able to run that produced artifact on windows, linux and mac, without touching anything else.

Second question: Why would javaw.exe not existing on linux/unix/mac even matter here? Because you rely (on javaw.exe) software that is not portable and not on other systems, it is only there on windows. If lanterna is a windows only library and it requires javaw, okay. But if should be compatible to linux/mac/*bsd/etc. - then one should only rely on whats on all systems, and that is java. Otherwise, such things happens with now gradle. Guess the same will happen with every distribution tool.

Afterall, "java.exe" and ".bat"-files aren't on linux/unix/mac, either. Thats wrong. The .bat file is generated on a linux system and the java.exe is java, just in another format. Javaw is something very different. Again: i build my software on linux, it works like a charm on linux, it works on *bsd, mac, etc. - but not on windows, because of javaw. Its like relying on a windows curl .exe instead of the curl library that can be used anywhere.

right now i use sed to replace "java.exe" with "javaw.exe" in the bat file. but thats nasty.

— Reply to this email directly, view it on GitHub https://github.com/mabe02/lanterna/issues/593#issuecomment-1909690571, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDBMWG6P7HNSRVWVAPPF3YQINAPAVCNFSM6AAAAABCI63DCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBZGY4TANJXGE . You are receiving this because you commented.Message ID: @.***>

damnms commented 10 months ago

ideally make the double-click on .bat to open the "DOS-box"

The gradle distribution tool (i prefer that over maven) generates 1 distribution that should work everywhere, which contains a /bin/app.bat (all win) and a /bin/app.sh (all linux/unix-like) and executes the packaged "fat-jar".

"lanterna for DOS-box"?

open the "DOS-box" and show the lanterna UI inside that dos-box.

that sounds exactly what i would have thought it does when i start that. i am very very unfamiliar with windows, i use it only at weekends for 1-2 AAA games that have cheat protection (and therefore dont work on linux). Is there any roadmap/ETA/what needs to be done/documentation/etc.?

avl42 commented 10 months ago

Apparently, you still do more Windows than me. And that's why I can't help you more than passing on hints to you from memory that I gathered in the last few years.

You need to get the sources of lanterna (best clone the repo on github, check out - so you can later create a PR for the changes) Then, add "native-integration" (sibling of "src") to the sources, make sure that "JNA" is available, and see if it compiles, or apply changes such that it compiles.

If this is all too complicated, then just stick with "sed"ing the ".bat" ...

On Thu, Jan 25, 2024 at 10:46 AM damnms @.***> wrote:

ideally make the double-click on .bat to open the "DOS-box"

The gradle distribution tool (i prefer that over maven) generates 1 distribution that should work everywhere, which contains a /bin/app.bat (all win) and a /bin/app.sh (all linux/unix-like) and executes the packaged "fat-jar".

"lanterna for DOS-box"?

open the "DOS-box" and show the lanterna UI inside that dos-box.

that sounds exactly what i would have thought it does when i start that. i am very very unfamiliar with windows, i use it only at weekends for 1-2 AAA games that have cheat protection (and therefore dont work on linux). Is there any roadmap/ETA/what needs to be done/documentation/etc.?

— Reply to this email directly, view it on GitHub https://github.com/mabe02/lanterna/issues/593#issuecomment-1909772119, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIDBMX2E7L3HEOGUFGKKBTYQISXXAVCNFSM6AAAAABCI63DCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBZG43TEMJRHE . You are receiving this because you commented.Message ID: @.***>

damnms commented 10 months ago

but when JNA is used, that would mean there are 2 releases for lanterna then, one for windows and one for all others, right?

just took a look at the code, so it uses some windows handlers but nothing else is shipped with it, so still possible to use 1 release. i will take a look at it and see how far i come.

avl42 commented 10 months ago

Once you get so far, you get some big jar file, that will also include those class files for windows-only, but that shouldn't hurt anywhere else.

The logic in DefaultTerminalFactory already attempts to load WindowsTerminal on Windows, and only goes to moan about javaw, if that failed. For this, you should of course use the DefaultTerminalFactory and not instanciate Terminal classes directly, but that's the recommended way, anyway.