Is 32bit ConPTY/OpenConsole supposed to work on 64bit Windows? #20391
|
I've been looking at getting ConPTY from nuget rather than using the variant bundled with windows for the terminal I maintain, but I've run into an issue: the 32bit version of conpty doesn't seem to work on 64bit Windows. 64bit ConPTY and OpenConsole work fine with a 64bit build of my terminal - I can launch cmd in a PTY, or j4james' games that use soft-fonts and it all works properly. But the 32bit ConPTY and OpenConsole alongside a 32bit build of my terminal not so much. CreateProcess doesn't report an error, but when my terminal goes to wait on the process its already dead. I spent a while trying to figure out where my bug is, but then I noticed that the 32bit version of OpenConsole doesn't seem to work either - it just exits immediately. Is this expected behaviour? Or is there something special that needs to be done for 32bit ConPTY to work on 64bit Windows? If its just incompatible then I guess I'll adjust 32bit builds of my terminal to go straight to the implementation provided by kernel32 if it detects its running on 64bit windows. |
Replies: 1 comment 6 replies
|
Ok, so. The console host (openconsole) needs to match the kernel architecture and the conpty shim (conpty.dll) needs to match the application architecture. We have build rules in the NuGet package that should add all required architectures to the final build directory, but I am certain that for reasons1 they don't always work. If you deploy a 32-bit terminal, it needs to come with a 32-bit openconsole for 32-bit kernels and a 64-bit openconsole for when you are running under WOW64 on 64-bit kernels. We talk about this in one (?) of the props files in the package (here), but could stand to make it clearer in the README. Sorry about the complication! Footnotes
|
|
(If you intend to run on earlier versions of Windows than 24H2, you technically need to include the ARM64 OpenConsole in your x86 build for the same reason - OpenConsole wants to run in the same architecture as the kernel, and your application could run as x86 on ARM64.) |
|
I think that all makes sense! I'm not using msbuild currently, so I've just got a task in github actions to grab the nuget package, expand it, and then fetch out the conpty.dll and openconsole.exe architecture that matches which ever target architecture the terminal is being built for. Not ideal, but replacing nmake is too big a project for the near future. Unfortunately I don't have an install program yet (every time I've looked at wix I've quickly become motivated to work on something else), so the 32bit package is just a zip file that contains contains all the 32bit binaries including the 32bit openconsole.exe and as a result it won't work properly on 64bit Windows. Ideally users will ignore the 32bit package unless they really need it, but I'm sure some people won't and might wonder why PTY sessions don't work. I saw this and hoped that might be the solution: Plan B will probably just be to have the terminal detect its running under wow64 and load conpty from kernel32 rather than the bundled conpty.dll. Degraded terminal emulation for PTY sessions would be better than not working at all I think. |
Ah! Those are directory names. Keep (Technically, you could keep the "same architecture as my application" one in the root folder and only put the "foreign architecture" ones in folders, but it may make it less clear rather than more clear!) |
|
Ahhh, that makes more sense - I did think having the architecture name on the front of the file name looked odd though there wasn't any reason it couldn't be done that way. I guess if I was using msbuild all of this would have just worked automatically and my problems are all down to me still using nmake. Keeping the "same architecture" openconsole.exe in the root folder didn't work, but moving both into x86\openconsole.exe and x64\openconsole.exe did! The x86-32 build now happily loads the latest conpty.dll on x86-64 windows I guess getting access to passthrough mode allowing this to work: I'll have to dig out the Raspberry Pi and do some testing on ARM64 too, but I assume the x86-32 build ought to include all three flavours of openconsole.exe, while the x86-64 build would contain only x64 and arm64, and the arm64 build would contain only the arm64 flavour because it doesn't run anywhere else. And that way whatever platform its run on, it should pick up the right version of openconsole.exe automatically and work correctly. Thanks for putting me back on the right path! |
|
Amazing! Kermit 95 is a name I haven't thought about in a loooong time.
Yep, that's exactly it. Also, "Hacked-up version of ARM64 Windows on a Raspbery Pi" gang, unite! :D |
Yep, its a pretty ancient program now - layers of history under an ocean of #ifdefs!
It runs surprisingly well! I've often wondered why it isn't officially supported in some way as they're so much more accessible (both in price and availability) than anything else, but I guess it probably doesn't work quite well enough to be an official thing. And I can confirm that the x86, x86-64 and native arm64 builds of K95 all work nicely under arm64 windows 11 complete with up-to-date conpty. The x86 emulator really works quite well - the non-native builds are barely any slower even on a Rasberry Pi. |
Ah! Those are directory names. Keep
openconsole.exebut put the arch-specific ones inx64andx86.(Technically, you could keep the "same architecture as my application" one in the root folder and only put the "foreign architecture" ones in folders, but it may make it less clear rather than more clear!)