Oh.. uh that program doesn't window stuff. Heh, that program is VNC, it lets you view someone elses computer if they allow you. In this case, the person on the other end of the VNC connection is running a game at fullscreen, otherwise you'd see a desktop with seperate windows inside that window.
Sorry I can't help you out, but I thought letting you know about that would clear a bit up.

??mabye vmware can force you to run in a window??
vmware homepage

a virtual machine would do exactly what you would want - in theory.

a hell of a long work-around, the final drawback to it ( besides the fact that you actually would need a second OS installed side by side with your current ) is thta virtual machines have a huge performance impact, meaning that the full screen game that you want to run windowed would do so ( albeit on a different OS running on a virtual machine ), but at a huge cost in speed and usefulness.

now i don't know a whole lot about graphics programming, but i'm pretty sure that those full screen applications aren't 'hacking' into the windows display at all - they are actually running full-screen to enable them to take full advantage of the capabilities of your graphics card.

Hello,

if the program can be run inside Linux (using wine or winex), can try using Gnome. Gnome 2.4 has a feature called new-login in a nested window, i.e. it creates a new workspace (inside a window) where you can login again as another user). Really cool.

Anyone know for any software or any technique to implement this on windows

Thanks.

I can think of a way, but it's definately not easy.

The problem lies in that fullscreen modes are handled by the graphics card directly - DirectX, for example, can completely take over the entire screen and not allow anything else to write to it. Windowed mode is a completely different setup, where Windows "tells" the application where it can display info (I'm oversimplifing, but you get the idea).

My idea would be this : write a virtual device driver to emulate a second monitor. That is, a driver would tell the motherboard (and therefore the gfx card) that there is a monitor present, and would handle all the input/output, but would redirect it to a window. That way you could run anything in "fullscreen" mode on the virtual monitor, which would display it in a window on the real monitor.

I have absolutely no idea how to do this though - I've never worked with multiple monitors, and I have zero experience with device driver development. But maybe someone else does?...

char: (good reminder)
that is a feature if the x window system when used on a multi-user system, you can create a window anywhere you want and log in to the system. it has been available in linux long before gnome 2.4 I remember doing it once in mandrake 6 a few years ago. It's basically the same thing that you do in a console mode when you switch to a different tty and login as a different user(as long as you haven't booted into single user mode)
My point here is that it could also work in windows if you could get an x implementation that supported it.
Windows XP is suppossed to be a fully multi-user os and they have sort of shown it with their fast user swutching. I think that there is an X implementation for windows (I think that Methodik was using it for a bit - cygwin I think it's called. it might be able to do this)
I honestly don't know if this would work but if it did, it would be a lot less overhead than a fullblown virtual machine.(It might even be usable)

as for grigri
I don'e think you can do that because I'm pretty sure that you cannot have 2 monitors within each other. whenever I've worked with multiple monitors I've never even been able to get them to overlap. and if you could, a device driver for a virtual monitor would be very difficult to implement. you would need a way for the videocard to redirect output to software that would reformat it in ram and would then send it back to the videocard for output on the display. This would be murder on performance, say the virtual monitor was 640x480 16bit color, that would require 600K of ram to store the screen and it would have to be sequential so that it could be given to the videocard at a reasonable speed. You could not access the ram at any point that the videocard is retrieving this information, and you would need to do that for every frame that is displayed.
That would be murder on the agp bus and would slow your entire system insanely.
On the bright side this would work better than a virtual machine like I sugessted.

Methodik is correct about how they are doing it, they can only get full performance by running in full screen, they are using commands that execute in the gpu and don't talk back to the operating system(most of the time)

I agree - it might be possible, but it's not practicable. I'm not sure why anyone would want to do this anyway... fullscreen, by definition, gives aone application total control over the screen, thus maximising display speed. Forcing a "fullscreen" app to work in a window, any way you hack it, is going to be intolerably slow.

Thanks fallout,

I have been using cygwin, and have try the x-server too. It's good, I can run gimp in Linux and have the window showed up in my windows screen. There's also what's called XDCMP, which can get remote GDM login, but had never tried it.

Speaking about second monitor, how about screensaver preview. I have never made a screensaver, but isn't in the preview mode, you can (have to) get a handle to a window, and then send anything the screensaver paint to the window.

Thanks.

by the way, you mentioned using gimp in cygwin - gimp is also available for the win32 platform.

Screensaver programs have to handle that themselves - in preview mode, they receive a switch and a window handle on the command line, and it's down to them to display it in the preview window. If they don't, the screensaver would just run normally.

You need to be logged in to post. To log-in, or to register an account go -there.