runapp works only when nano-x was built about microwindows

[ghaerr]

Thanks for bringing this to my attention, I'll fix it.

Of course runapp isn't at all required to run the win32 api binaries, but the docs were rewritten to suggest using it to execute any binary so users don't have to know about nano-X versus win32 startup. Given that it already checks the binary for a "mw" prefix and skips the server start, I will have it skip the server presence check in that case.

[ghaerr]

I see. Your design is actually very similar to the way that the Windows system emulator Parallels can be setup to run on OSX. That is, every emulated win32 application window can be setup to appear as a separate native-OS window. Kind of cool.

I will have to think about how this might work, basically the win32 binary would run natively, and all window calls would be allocated separate X11 windows to draw into. At first thought, this would mean that the Microwindows screen device would have to move from being a global, to being able to be created as seperate instances, each with its own drawing region. That's kind of hard.

In some sense, it might be easiest to just run a separate copy of MIcrowindows for each application, which just delays screen allocation until the CreateWindow call. And that would possibly work well until that same application threw up a dialog box, which would then have to run in a separate Microwindows instance, and that won't work.

I'll continue thinking about it!

[ghaerr]

@rofl0r : I fixed runapp, finally.

Also added an experimental MW_FEATURE_RESIZEFRAME that resizes the outer OS frame around the application automatically as per your discussion above. This now works for win32 as well as Nano-X apps (requires LINK_APP_INTO_SERVER for Nano-X). Pretty cool actually, as it allows any Microwindows or Nano-X application to run standalone on the X11 desktop. Here's a screenshot.

[rofl0r]

i'd suggest to look for the binary that's about to be launched instead

[rofl0r]

btw unrelated question, is there a way to make the win32 apps "free-floating" vs living inside a win95-colored window ?

[ghaerr]

What do you mean? Do you mean not running within a window within the 800x600 screen? So that it just displays using the full screen size but with no window frame?

[rofl0r]

exactly, so it behaves like any other x11 desktop app

[ghaerr]

If you create your main window without using the default style of WS_OVERLAPPEDWINDOW, but instead just use, perhaps WS_POPUP, and then specify the x,y params as 0,0 that should work, try that.

[rofl0r]

for clarification, this:

instead of

[ghaerr]

I just tested with WS_POPUP on demos/mwin/mwdemo2.c and that works... except that not only do you have to set x,y to 0,0 but the width, height to the screen size, which you can query using GetSystemMetrics(SM_CXSCREEN...

The system is compiled in to use a specific screen size, so this is problematic if you want to run different win32 apps and have them change the Microwindows screen size. But that could also be done with a patch, but it might be complicated given that the app would have to run before knowing the screen size expected.

Also, on the example above, its a bit more complicated, wince mwdvetest is actually a dialog box, rather than a standalone popup-window.

Which case are you looking for?

[ghaerr]

Here's mwdemo2 with the mods suggested.

[rofl0r]

Which case are you looking for?

I've long played with the thought that the lack of a stable GUI toolkit is the reason we still haven't seen the year of the linux desktop, and that using the win32 api which is unchanged since win95 would be the optimal candidate, since it would allow GUI developers to use the same code for linux and windows (and it would allow to simply recompile existing OSS windows gui apps for linux by linking against -lgdi32 or similar)

[rofl0r]

(if you embed your patch snippet above into triple ` characters (each one on a line by itself) it would become way more readable)

[ghaerr]

An issue there will be that each application runs within its own Microwindows system, which is using then run again with X11, or on the single frame buffer linux console. Thus, multiple applications work on X11 but not on frame buffer.

I have a patch that I haven't submitted that allows multiple win32 apps to run at the same time, within a single frame buffer or X11 window. That's not quite what you need it seems though.

[ghaerr]

patch.txt
Thanks, here's the patch, you're right GitHub didn't take my last paste!

[ghaerr]

Here's a screenshot of multiple win32 apps running in the same process.

[rofl0r]

I have a patch that I haven't submitted that allows multiple win32 apps to run at the same time, within a single frame buffer or X11 window. That's not quite what you need it seems though.

right, for my use case every program would need to create a standalone X11 window for every win32 windows it spawns, and not the "desktop mode" seen in your screenshot above

[ghaerr]

In order to make your idea work, we need to determine how the system will know the client window size by somehow running the client until the first CreateWindow call, then initializing the driver subsystem to the client window size. Currently the system isn't really written for that. But adding essentially a "realloc" might be feasible.

Another potential issue with your idea of a win32 linux desktop is that Microwindows only implements a small but usable subset of the user32 and gdi32, and real Windows programs typically require hugely more libs. Thus Wine was born, and look how big it is, in order to run everything!

[rofl0r]

determine how the system will know the client window size

client window size would mean the size of the X11 desktop? not following yet...

real Windows programs typically require hugely more libs. Thus Wine was born, and look how big it is

right... i was just playing around with wine sources and examined the "notepad" program source code. apart from the gui code, it seems to access the windows registry to get the dpi value of the desktop. without being very familiar with wine's internals, i suspect it will spin up some on-demand server processes to serve global registry accesses and other similar things.
which seems suboptimal/overdesigned for simple GUI purposes.
this could eventually be solved by mimicking the registry related api calls and just serving static values from a configuration file, or by simply patching out the related code and use a hardcoded dpi value...

[ghaerr]

A win32 "client size" is the size of the application's window not including the title bar and stuff that you don't want. What you are asking for is having both the win32 app (client size) equaling the size of the X11 window that Microwindows starts up. By default, Microwindows starts up with whatever you put in your config file, mine is 1024x768. So that would have to be down-sized to your win32 app's client size specified in the CreateWindow call. And that call is done way after Microwindows starts up, since Microwindows allocates the X11 display when starting, THEN runs the win32 app.

[ghaerr]

I showed you a screen shot that was done in a 4 line patch where the win32 app was changed to display at 0,0, and the client size was 1024x768. But I think what you want is for the X11 display window to match the win32 app's requested window size, without window dressing. That's the problem I'm describing above.

In any case, let me know how I might help you, if you need a mod.

[rofl0r]

having both the win32 app (client size) equaling the size of the X11 window that Microwindows starts up

oh, alright. thinking about this design, would this even work if the main app window spawns other windows outside its own visible region (think gimp's floating toolkit windows)? i think it wouldn't. therefore in the theoretical mode i'm interested in, there would have to be no top "desktop" window, and each program window would need to be a separate X11 window, and microwindows wouldn't have to deal with mouse events outside the windows nor window positioning.

In any case, let me know how I might help you, if you need a mod.

even if my idea of having a win32-linux-desktop would need to be shelfed (still evaluating) i think this could be a very interesting usecase to get a number of existing win32 gui apps working as "native" linux/mac apps. i'm unsure whether the idea would play well with the existing code design, but maybe it could be implemented relatively easily and modular, without huge effort?

[rofl0r]

cool, that looks really good! i'll try to test it out ASAP