Please keep this on the vbox-dev mailing list, as mails directly to
particular people bear the risk of not getting responses in quite some
time if the workload is too high.

Brad Robinson wrote:
I don't know why MS decided on a flag on createprocess to hide the window -
just the way it is I guess.

Do you know for sure that there is no flag which can be set in the
executable to avoid the console window? That's where I would start
digging if I'd have time.

Regarding your comment:

This is expected behavior - and you can change it by catching the shutdown. So far all environments which started VMs in the background took care of handling host shutdown already, this is why there was no need to have code in all frontends.

What I'm seeing is this:

* I have a Win32 GUI app that launches VBoxHeadless to run the VM.
* On Windows shutdown/logout, the VBoxHeadless process is already gone by
the time my app gets the WM_ENDSESSION message (sent by Windows on
shutdown).
* The VBoxHeadless process seems to be forcefully terminated. It certainly
doesn't save the machine state and after rebooting the host the VBox front
end shows it's state as aborted.  You can see this yourself - on windows run
up VBoxHeadless and then log out of Windows. Log back on and run up
VirtualBox main GUI and you'll see it shows state as aborted.

The VirtualBox-related apps don't check for WM_ENDSESSION, and what
you're observing might be caused by the fact that VBoxSVC gets killed
(or COM handles WM_ENDSESSION) pretty early. VBoxSVC needs to survive
until the last VM is saved.

In other words, my app could save it and shut it down cleanly but Windows
jumps in before me.  I don't understand "no need to have code in all
frontends" - don't I need to have code to trap the shutdown and save the VM?

This was talking about the hypothetical situation where VBoxHeadless
would detect WM_ENDSESSION itself, and reacts to it by saving state.
This sounds implementable to me, it certainly is not current behavior.

I'm now considering swapping back to the other approach of running the VM
in-process (OpenSession), but really need a solution for the blank VRDP
screen issue - I don't believe this is something I can fix myself.  The log
file sharing violation I could probably fix myself and contribute if
necessary.

It's totally unclear to me why you get a blank screen via RDP. The VRDP
server in VirtualBox works on Windows host as well, so you would need to
provide more details what you mean exactly by "custom front end". You
can set up the VRDP server via the SDK, and actually the VBoxHeadless
code you can get via OSE is not "censored", it is just built with a few
lines of code disabled, which establish the connection to the closed
source VRDP server component. With the available information everything
would be speculation (like that the framebuffer setup isn't done correctly).

Note that reusing OSE source code (covered by GPL) to talk to the
PUEL-licensed VRDP server component is a GPL violation.

Klaus


Any help (especially on the VRDP issue) would be greatly appreciated.

Brad



-----Original Message-----
From: [email protected] [mailto:[email protected]] Sent: Tuesday, 27 October 2009 8:15 PM
To: Brad Robinson
Cc: [email protected]
Subject: Re: [vbox-dev] Custom front-end using non-OSE SDK

Brad Robinson wrote:
Hi Klaus,

To get a console process to launch without a console you just need to set
the CREATE_NO_WINDOW flag on the call to CreateProcess. I'm doing this now
in my app to launch VBoxHeadless.  The problem now is that on

It sounds wrong to need a flag when starting the process. The process should automatically start without that window.

shutdown/logout, windows just kills that process without giving it a
chance
to shutdown.  VBoxHeadless doesn't seems to invoke the code to save state
and my app doesn’t seem to get a chance to cleanly save state it either.

This is expected behavior - and you can change it by catching the shutdown. So far all environments which started VMs in the background took care of handling host shutdown already, this is why there was no need to have code in all frontends.

Disappointed to hear that Windows host is not a priority. I'd be happy to
help resolve some of these issues but I need these fixes in the non-OSE
VBox
since I really need the RDP support.  Is there a process for getting OSE
fixes rolled into the retail build and how long does this typically take?

Just submit the changes to us (see the Contribution page on virtualbox.org). We never rejected any sensible contributions, and they do end up in the non-OSE version as well. The timeframe for that depends on many factors (risk of breakage, next maintenance release, ...), but we try to keep delays at a minimum.

Klaus

-----Original Message-----
From: [email protected] [mailto:[email protected]] Sent: Tuesday, 27 October 2009 1:23 AM
To: Brad Robinson
Cc: [email protected]
Subject: Re: [vbox-dev] Custom front-end using non-OSE SDK

Brad Robinson wrote:
Hi Josh,

Under windows, when running as a logged on user yep, ugly black console
window appears.  But I can use CreateProcess to launch VBoxHeadless and
get
it running hidden.  Still to get this working properly in-process would
be
much nicer.
This is a known bug, and has been reported on this list several times already. And since it's a bug you're welcome helping to hunt it down. Since I don't know the Windows API by heart, I don't know what knobs to tune to get a process started without this console window at all - which is the goal. Hiding the window is just a workaround.

Note that this issue isn't a high priority, since there is no demand for Windows as a host OS. Don't ask me why.

I haven't looked at VBoxWeb - I only installed VirtualBox for the first
time
last Thursday, so this is all new to me.
This certainly makes no difference here. The
Brad

-----Original Message-----
From: Josh Wright [mailto:[email protected]] Sent: Tuesday, 27 October 2009 12:28 AM
To: Brad Robinson
Cc: [email protected]
Subject: Re: [vbox-dev] Custom front-end using non-OSE SDK

OpenRemoteSession(... "vrdp"...) opens a console for you?

You might want to look at the VBoxWeb code, since it also starts
headless/vrdp sessions.

http://code.google.com/p/vboxweb/source/browse/trunk/VBoxWebSrv.py#398

~JW

On Mon, Oct 26, 2009 at 9:18 AM, Brad Robinson
<[email protected]> wrote:
Thanks Frank,

I did look quickly at VBoxSDL, but couldn't really find anything that
helped
with this specific problem.

Regarding the VRDP, it's a pity that a custom front-end can't support
that
through the SDK.  Is that a deliberate measure, or should the SDK
support
it, or could it export a method that wires up those frame buffers?

Regarding the sharing violation, I suspect the log file is just not
getting
closed correctly.  In my case I was trying to run the same VM twice
(once
after the other) in the one process.  All the standard front ends seem
to
run one VM and then shutdown - which would hide an unreleased file
handle.
My interim approach to this is going to be simply launching
VBoxHeadless.exe
- it solves both problems for me but the code is a lot messier.

In short what I'm trying to do here is run a headless VM, but not have
the
console window show up - so OpenRemoteSession(... "vrdp"...) is no go to
me.
Anyway, I'll get you a sample project ASAP so you can investigate what
I'm
seeing.

Regards
Brad


-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Monday, 26 October 2009 11:56 PM
To: Brad Robinson
Subject: Re: [vbox-dev] Custom front-end using non-OSE SDK

Brad,

please reply to the mailing list if possible because I get tons of mails
each day and probably other developers want to follow the discussion as
well.

On Monday 26 October 2009, Brad Robinson wrote:
Thanks for getting back to me on this.  I'll put together a simpler
example as my real project brings in a couple of custom libraries you
won't be interested in.  Shall I just email it directly to you?
That would be possible. Or, if the compressed code isn't too long, you
could
post it to the mailing list as well.

Btw: I've noticed in the VBoxHeadless OSE source code there's code
that sets a "new VRDPFramebuffer" to each display of the console...
this is what I suspect I'm missing, but not sure how to implement with
the
SDK.

Right, the VRDPFramebuffer is closed source and actually I'm not sure if
you
will be able to write a custom frontend which can do RDP. Did you
already
have a look at VBoxSDL?



_______________________________________________
vbox-dev mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-dev

Reply via email to