[vbox-dev] Custom front-end using non-OSE SDK

Tue Oct 27 14:40:38 GMT 2009

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: Klaus.Espenlaub at Sun.COM [mailto:Klaus.Espenlaub at Sun.COM] 
> Sent: Tuesday, 27 October 2009 8:15 PM
> To: Brad Robinson
> Cc: vbox-dev at virtualbox.org
> 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: Klaus.Espenlaub at Sun.COM [mailto:Klaus.Espenlaub at Sun.COM] 
>> Sent: Tuesday, 27 October 2009 1:23 AM
>> To: Brad Robinson
>> Cc: vbox-dev at virtualbox.org
>> 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:jshwright at gmail.com] 
>>> Sent: Tuesday, 27 October 2009 12:28 AM
>>> To: Brad Robinson
>>> Cc: vbox-dev at virtualbox.org
>>> 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
>>> <brobinson at cantabilesoftware.com> 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: Frank.Mehnert at Sun.COM [mailto:Frank.Mehnert at Sun.COM]
>>>> 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?