Terminal/Console Window

[mateli]

Run terminal applications in a window similar to the Terminal app.

Perhaps include command.com/cmd.com interpreter. Dosbox has this but that is of course different from a windows command shell.

[evmar]

Are you suggesting the app spawn its own window to render text?
What is the use case? You can already run via a terminal, and on web we already render some text.

[mateli]

The use case are having more than one text application at once, side by side.

For example typing the command "start cmd.exe" in windows opens up a new window with a command prompt. That is one very common use case.

Or is the idea that we need to run a distinct instance of retrowin32 for each Windows application?

[evmar]

You need a distinct instance per Windows application, yes.

[mateli]

Buy is that a design choice or just not implemented yet?

[evmar]

A design choice, I think.

[mateli]

Well that's going to be a major disappointment for most users. It's a serious limitation for several reasons and many applications will even be unable to run. For example IDE:s that launches compilers and linkers. Also implementing features like IPC will be rather difficult.

[evmar]

I believe Wine also cannot run multiple processes at once. It instead spawns multiple copies of Wine, which is what I think I'd do for that kind of use case.

[mateli]

Wine is not an emulator. It does run a single instance called wineserver and runs each Windows process as a unix process. Without emulation this is the only way to run multiple Windows applications. And it has quite a few problems.

As such wine both have a desktop mode where all windows applications share a single actual window which looks a lot like running an emulator would.

If retrowin32 is going to aim for being like wine then similar functionality is needed. With wine desktop mode you do get a desktop with multiple windows on it. Both console and graphical windows from multiple applications.

However implementing something like wineserver to achieve this is in my opinion simply excessive. It also have significant impact on performance which is one of the things that makes wine so slowly.

Instead extending the system you have for running multiple threads into running multiple processes means that you don't need something like wineserver.

[mateli]

To put it like this. Wine has a huge amount of code to deal with the fact that they want to run Windows applications directly on x86 hardware. This code will make it so that applications running in wine can never perform as well as applications running natively if they do any significant amount of winapi calls that depends on winserver or similar. Add running wine in qemu for non-x86 compatibility and all potential advantages this provides are lost.

As a fun off topic fact running a proprietary compiler toolchain (IAR) on wine in qemu on raspberry pi 4 is still faster than running it on a brand new windows 11 computer with all the anti-malware stuff IT departments put in Windows 11.

But back to the point. Running wine in desktop mode has disadvantages that a pure emulator high level emulator doesn't need to have.

In fact for example adding an IPC layer when the applications are running as a single host process are going to provide a lot faster IPC than is possible when running separate host processes. This because we're not actually doing any IPC. Which means that such a feature will be faster than in wine where it goes through wineserver.

File access is in wine IPC calls to wineserver which adds a significant performance bottleneck.

This list of course goes on and on. While many of wines features doesn't yet exit in retrowin32 it's useful to plan think about them when making design choices.

And to take things further I'm going to provide another use case. Raspberry Pi with retrowin32 running directly on the frame buffer. Full screen with no x11, no Wayland or anything like that. The only windowing we get is what retrowin32 itself renders on it's own desktop. If retrowin32 can't run multiple applications at once this means that we need to close one application to start another because the framebuffer can't easily be shared.