VirtualBox

source: vbox/trunk/doc/manual/en_US/SDKRef.xml@ 105499

Last change on this file since 105499 was 105400, checked in by vboxsync, 5 months ago

Docs: Replacing User Manual with User Guide in our reference manual.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Id Revision
File size: 319.5 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3 Copyright (C) 2006-2023 Oracle and/or its affiliates.
4
5 This file is part of VirtualBox base platform packages, as
6 available from https://www.virtualbox.org.
7
8 This program is free software; you can redistribute it and/or
9 modify it under the terms of the GNU General Public License
10 as published by the Free Software Foundation, in version 3 of the
11 License.
12
13 This program is distributed in the hope that it will be useful, but
14 WITHOUT ANY WARRANTY; without even the implied warranty of
15 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
16 General Public License for more details.
17
18 You should have received a copy of the GNU General Public License
19 along with this program; if not, see <https://www.gnu.org/licenses>.
20
21 SPDX-License-Identifier: GPL-3.0-only
22-->
23<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
24 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"[
25<!ENTITY % all.entities SYSTEM "all-entities.ent">
26%all.entities;
27]>
28
29<book>
30 <bookinfo>
31 <title>&VBOX_PRODUCT;</title>
32
33 <subtitle>Programming Guide and Reference</subtitle>
34
35 <edition>Version &VBOX_VERSION_STRING;</edition>
36
37 <corpauthor>&VBOX_VENDOR;</corpauthor>
38
39 <address>http://www.virtualbox.org</address>
40
41 <copyright>
42 <year>2004-&VBOX_C_YEAR;</year>
43
44 <holder>&VBOX_VENDOR;</holder>
45 </copyright>
46 </bookinfo>
47
48 <chapter>
49 <title>Introduction</title>
50
51 <para>VirtualBox comes with comprehensive support for third-party
52 developers. This Software Development Kit (SDK) contains all the
53 documentation and interface files that are needed to write code that
54 interacts with VirtualBox.</para>
55
56 <sect1>
57 <title>Modularity: the building blocks of VirtualBox</title>
58
59 <para>VirtualBox is cleanly separated into several layers, which can be
60 visualized like in the picture below:</para>
61
62 <mediaobject>
63 <imageobject>
64 <imagedata align="center" fileref="images/vbox-components.png"
65 width="12cm"/>
66 </imageobject>
67 </mediaobject>
68
69 <para>The orange area represents code that runs in kernel mode, the blue
70 area represents userspace code.</para>
71
72 <para>At the bottom of the stack resides the hypervisor -- the core of
73 the virtualization engine, controlling execution of the virtual machines
74 and making sure they do not conflict with each other or with whatever else
75 the host computer is doing.</para>
76
77 <para>On top of the hypervisor, additional internal modules provide
78 extra functionality. For example, the RDP server, which can deliver the
79 graphical output of a VM remotely to an RDP client, is a separate module
80 that is only loosely tacked onto the virtual graphics device.</para>
81
82 <para>What is primarily of interest for purposes of the SDK is the API
83 layer block that sits on top of all the previously mentioned blocks.
84 This API, which we call the <emphasis role="bold">"Main API"</emphasis>,
85 exposes the entire feature set of the virtualization engine below. It is
86 completely documented in this SDK Reference -- see <xref
87 linkend="sdkref_classes"/> and <xref linkend="sdkref_enums"/> -- and
88 available to anyone who wishes to control VirtualBox programmatically.
89 We chose the name "Main API" to differentiate it from other programming
90 interfaces of VirtualBox that may be publicly accessible.</para>
91
92 <para>With the Main API, you can create, configure, start, stop and
93 delete virtual machines, retrieve performance statistics about running
94 VMs, configure the VirtualBox installation in general, and more. In
95 fact, internally, the front-end programs
96 <computeroutput>VirtualBox</computeroutput> and
97 <computeroutput>VBoxManage</computeroutput> use nothing but this API as
98 well -- there are no hidden backdoors into the virtualization engine for
99 our own front-ends. This ensures the entire Main API is both
100 well-documented and well-tested. (The same applies to
101 <computeroutput>VBoxHeadless</computeroutput>, which is not shown in the
102 image.)</para>
103 </sect1>
104
105 <sect1 id="webservice-or-com">
106 <title>Two guises of the same "Main API": the web service or
107 COM/XPCOM</title>
108
109 <para>There are several ways in which the Main API can be called by
110 other code:<orderedlist>
111 <listitem>
112 <para>VirtualBox comes with a <emphasis role="bold">web
113 service</emphasis> that maps nearly the entire Main API. The web
114 service ships in a stand-alone executable
115 (<computeroutput>vboxwebsrv</computeroutput>) that, when running,
116 acts as an HTTP server, accepts SOAP connections and processes
117 them.</para>
118
119 <para>Since the entire web service API is publicly described in a
120 web service description file (in WSDL format), you can write
121 client programs that call the web service in any language with a
122 toolkit that understands WSDL. These days, that includes most
123 programming languages that are available: Java, C++, .NET, PHP,
124 Python, Perl and probably many more.</para>
125
126 <para>All of this is explained in detail in subsequent chapters of
127 this book.</para>
128
129 <para>There are two ways in which you can write client code that
130 uses the web service:<orderedlist>
131 <listitem>
132 <para>For Java as well as Python, the SDK contains
133 easy-to-use classes that allow you to use the web service in
134 an object-oriented, straightforward manner. We shall refer
135 to this as the <emphasis role="bold">"object-oriented web
136 service (OOWS)"</emphasis>.</para>
137
138 <para>The OO bindings for Java are described in <xref
139 linkend="javaapi"/>, those for Python in <xref
140 linkend="glue-python-ws"/>.</para>
141 </listitem>
142
143 <listitem>
144 <para>Alternatively, you can use the web service directly,
145 without the object-oriented client layer. We shall refer to
146 this as the <emphasis role="bold">"raw web
147 service"</emphasis>.</para>
148
149 <para>You will then have neither native object orientation
150 nor full type safety, since web services are neither
151 object-oriented nor stateful. However, in this way, you can
152 write client code even in languages for which we do not ship
153 object-oriented client code; all you need is a programming
154 language with a toolkit that can parse WSDL and generate
155 client wrapper code from it.</para>
156
157 <para>We describe this further in <xref
158 linkend="raw-webservice"/>, with samples for Java and
159 Perl.</para>
160 </listitem>
161 </orderedlist></para>
162 </listitem>
163
164 <listitem>
165 <para>Internally, for portability and easier maintenance, the Main
166 API is implemented using the <emphasis role="bold">Component
167 Object Model (COM), </emphasis> an interprocess mechanism for
168 software components originally introduced by Microsoft for
169 Microsoft Windows. On a Windows host, VirtualBox will use
170 Microsoft COM; on other hosts where COM is not present, VirtualBox
171 ships with XPCOM, a free software implementation of COM originally
172 created by the Mozilla project for their browsers.</para>
173
174 <para>So if you are familiar with COM and the C++ programming
175 language (or with any other programming language that can handle
176 COM/XPCOM objects, such as Java, Visual Basic or C#), then you can
177 use the COM/XPCOM API directly. VirtualBox comes with all the
178 necessary files and documentation to build fully functional COM
179 applications. For an introduction, please see <xref
180 linkend="api_com"/> below.</para>
181
182 <para>The VirtualBox front-ends (the graphical user interfaces as
183 well as the command line), which are all written in C++, use
184 COM/XPCOM to call the Main API. Technically, the web service is
185 another front-end to this COM API, mapping almost all of it to
186 SOAP clients.</para>
187 </listitem>
188 </orderedlist></para>
189
190 <para>If you are wondering which approach to choose, here are a few
191 comparisons:<table>
192 <title>Comparison web service vs. COM/XPCOM</title>
193
194 <tgroup cols="2">
195 <tbody>
196 <row>
197 <entry><emphasis role="bold">Web service</emphasis></entry>
198
199 <entry><emphasis role="bold">COM/XPCOM</emphasis></entry>
200 </row>
201
202 <row>
203 <entry><emphasis role="bold">Pro:</emphasis> Easy to use with
204 Java and Python with the object-oriented web service;
205 extensive support even with other languages (C++, .NET, PHP,
206 Perl and others)</entry>
207
208 <entry><emphasis role="bold">Con:</emphasis> Usable from
209 languages where COM bridge available (most languages on
210 Windows platform, Python and C++ on other hosts)</entry>
211 </row>
212
213 <row>
214 <entry><emphasis role="bold">Pro:</emphasis> Client can be on
215 remote machine</entry>
216
217 <entry><emphasis role="bold">Con: </emphasis>Client must be on
218 the same host where virtual machine is executed</entry>
219 </row>
220
221 <row>
222 <entry><emphasis role="bold">Con: </emphasis>Significant
223 overhead due to XML marshalling over the wire for each method
224 call</entry>
225
226 <entry><emphasis role="bold">Pro: </emphasis>Relatively low
227 invocation overhead</entry>
228 </row>
229 </tbody>
230 </tgroup>
231 </table></para>
232
233 <para>In the following chapters, we will describe the different ways in
234 which to program VirtualBox, starting with the method that is easiest to
235 use and then increasing in complexity as we go along.</para>
236 </sect1>
237
238 <sect1 id="api_soap_intro">
239 <title>About web services in general</title>
240
241 <para>Web services are a particular type of programming interface.
242 Whereas, with "normal" programming, a program calls an application
243 programming interface (API) defined by another program or the operating
244 system and both sides of the interface have to agree on the calling
245 convention and, in most cases, use the same programming language, web
246 services use Internet standards such as HTTP and XML to
247 communicate.<footnote>
248 <para>In some ways, web services promise to deliver the same thing
249 as CORBA and DCOM did years ago. However, while these previous
250 technologies relied on specific binary protocols and thus proved to
251 be difficult to use between diverging platforms, web services
252 circumvent these incompatibilities by using text-only standards like
253 HTTP and XML. On the downside (and, one could say, typical of things
254 related to XML), a lot of standards are involved before a web
255 service can be implemented. Many of the standards invented around
256 XML are used one way or another. As a result, web services are slow
257 and verbose, and the details can be incredibly messy. The relevant
258 standards here are called SOAP and WSDL, where SOAP describes the
259 format of the messages that are exchanged (an XML document wrapped
260 in an HTTP header), and WSDL is an XML format that describes a
261 complete API provided by a web service. WSDL in turn uses XML Schema
262 to describe types, which is not exactly terse either. However, as
263 you will see from the samples provided in this chapter, the
264 VirtualBox web service shields you from these details and is easy to
265 use.</para>
266 </footnote></para>
267
268 <para>In order to successfully use a web service, a number of things are
269 required -- primarily, a web service accepting connections; service
270 descriptions; and a client that connects to that web service. Connections
271 to the VirtualBox web service are governed by the SOAP standard, which
272 describes how messages are to be exchanged between a service and its
273 clients; the service descriptions are governed by WSDL.</para>
274
275 <para>In the case of VirtualBox, this translates into the following
276 three components:<orderedlist>
277 <listitem>
278 <para>The VirtualBox web service (the "server"): this is the
279 <computeroutput>vboxwebsrv</computeroutput> executable shipped
280 with VirtualBox. Once you start this executable (which acts as an
281 HTTP server on a specific TCP/IP port), clients can connect to the
282 web service and thus control a VirtualBox installation.</para>
283 </listitem>
284
285 <listitem>
286 <para>VirtualBox also comes with WSDL files that describe the
287 services provided by the web service. You can find these files in
288 the <computeroutput>sdk/bindings/webservice/</computeroutput>
289 directory. These files are understood by the web service toolkits
290 that are shipped with most programming languages and enable you to
291 easily access a web service even if you don't use our
292 object-oriented client layers. VirtualBox is shipped with
293 pre-generated web service glue code for several languages (Python,
294 Perl, Java).</para>
295 </listitem>
296
297 <listitem>
298 <para>A client that connects to the web service in order to
299 control the VirtualBox installation.</para>
300
301 <para>Unless you use some of the samples shipped with
302 VirtualBox, this needs to be written by you.</para>
303 </listitem>
304 </orderedlist></para>
305 </sect1>
306
307 <sect1 id="runvboxwebsrv">
308 <title>Running the web service</title>
309
310 <para>The web service ships in a stand-alone executable,
311 <computeroutput>vboxwebsrv</computeroutput>, that, when running, acts as
312 an HTTP server, accepts SOAP connections, remotely or from the same machine,
313 and processes them.<note>
314 <para>The web service executable is not delivered with the
315 VirtualBox SDK, but instead ships with the standard VirtualBox
316 binary package for your specific platform. The SDK contains only
317 platform-independent text files and documentation so thus the vboxwebsrv
318 binary is shipped with the platform-specific packages. Therefore the
319 information on how to run vboxwebsrv as a service is included in the
320 VirtualBox documentation and not the SDK.</para>
321 </note></para>
322
323 <para>The <computeroutput>vboxwebsrv</computeroutput> program, which
324 implements the web service, is a text-mode (console) program which,
325 after being started, simply runs until it is interrupted with Ctrl-C or
326 a kill command.</para>
327
328 <para>Once the web service is started, it acts as a front-end to the
329 VirtualBox installation of the user account that it is running under. In
330 other words, if the web service is run under the user account of
331 <computeroutput>user1</computeroutput>, it will see and manipulate the
332 virtual machines and other data represented by the VirtualBox data of
333 that user (for example, on a Linux machine, under
334 <computeroutput>/home/user1/.config/VirtualBox</computeroutput>; see the
335 VirtualBox User Guide for details on where this data is stored).</para>
336
337 <sect2 id="vboxwebsrv-ref">
338 <title>Command line options of vboxwebsrv</title>
339
340 <para>The web service supports the following command line
341 options:</para>
342
343 <itemizedlist>
344 <listitem>
345 <para><computeroutput>--help</computeroutput> (or
346 <computeroutput>-h</computeroutput>): print a brief summary of
347 command line options.</para>
348 </listitem>
349
350 <listitem>
351 <para><computeroutput>--background</computeroutput> (or
352 <computeroutput>-b</computeroutput>): run the web service as a
353 background daemon. This option is not supported on Windows
354 hosts.</para>
355 </listitem>
356
357 <listitem>
358 <para><computeroutput>--host</computeroutput> (or
359 <computeroutput>-H</computeroutput>): This specifies the host to
360 bind to and defaults to "localhost".</para>
361 </listitem>
362
363 <listitem>
364 <para><computeroutput>--port</computeroutput> (or
365 <computeroutput>-p</computeroutput>): This specifies which port to
366 bind to on the host and defaults to 18083.</para>
367 </listitem>
368
369 <listitem>
370 <para><computeroutput>--ssl</computeroutput> (or
371 <computeroutput>-s</computeroutput>): This enables SSL
372 support.</para>
373 </listitem>
374
375 <listitem>
376 <para><computeroutput>--keyfile</computeroutput> (or
377 <computeroutput>-K</computeroutput>): This specifies the file name
378 containing the server private key and the certificate. This is a
379 mandatory parameter if SSL is enabled.</para>
380 </listitem>
381
382 <listitem>
383 <para><computeroutput>--passwordfile</computeroutput> (or
384 <computeroutput>-a</computeroutput>): This specifies the file name
385 containing the password for the server private key. If unspecified
386 or an empty string is specified this is interpreted as an empty
387 password (i.e. the private key is not protected by a password). If
388 the file name <computeroutput>-</computeroutput> is specified then
389 then the password is read from the standard input stream, otherwise
390 from the specified file. The user is responsible for appropriate
391 access rights to protect the confidential password.</para>
392 </listitem>
393
394 <listitem>
395 <para><computeroutput>--cacert</computeroutput> (or
396 <computeroutput>-c</computeroutput>): This specifies the file name
397 containing the CA certificate appropriate for the server
398 certificate.</para>
399 </listitem>
400
401 <listitem>
402 <para><computeroutput>--capath</computeroutput> (or
403 <computeroutput>-C</computeroutput>): This specifies the directory
404 containing several CA certificates appropriate for the server
405 certificate.</para>
406 </listitem>
407
408 <listitem>
409 <para><computeroutput>--dhfile</computeroutput> (or
410 <computeroutput>-D</computeroutput>): This specifies the file name
411 containing the DH key. Alternatively it can contain the number of
412 bits of the DH key to generate. If left empty, RSA is used.</para>
413 </listitem>
414
415 <listitem>
416 <para><computeroutput>--randfile</computeroutput> (or
417 <computeroutput>-r</computeroutput>): This specifies the file name
418 containing the seed for the random number generator. If left empty,
419 an operating system specific source of the seed.</para>
420 </listitem>
421
422 <listitem>
423 <para><computeroutput>--timeout</computeroutput> (or
424 <computeroutput>-t</computeroutput>): This specifies the session
425 timeout, in seconds, and defaults to 300 (five minutes). A web
426 service client that has logged on but makes no calls to the web
427 service will automatically be disconnected after the number of
428 seconds specified here, as if it had called the
429 <computeroutput>IWebSessionManager::logoff()</computeroutput>
430 method provided by the web service itself.</para>
431
432 <para>It is normally vital that each web service client call this
433 method, as the web service can accumulate large amounts of memory
434 when running, especially if a web service client does not properly
435 release managed object references. As a result, this timeout value
436 should not be set too high, especially on machines with a high
437 load on the web service, or the web service may eventually deny
438 service.</para>
439 </listitem>
440
441 <listitem>
442 <para><computeroutput>--check-interval</computeroutput> (or
443 <computeroutput>-i</computeroutput>): This specifies the interval
444 in which the web service checks for timed-out clients, in seconds,
445 and defaults to 5. This normally does not need to be
446 changed.</para>
447 </listitem>
448
449 <listitem>
450 <para><computeroutput>--threads</computeroutput> (or
451 <computeroutput>-T</computeroutput>): This specifies the maximum
452 number or worker threads, and defaults to 100. This normally does
453 not need to be changed.</para>
454 </listitem>
455
456 <listitem>
457 <para><computeroutput>--keepalive</computeroutput> (or
458 <computeroutput>-k</computeroutput>): This specifies the maximum
459 number of requests which can be sent in one web service connection,
460 and defaults to 100. This normally does not need to be
461 changed.</para>
462 </listitem>
463
464 <listitem>
465 <para><computeroutput>--authentication</computeroutput> (or
466 <computeroutput>-A</computeroutput>): This specifies the desired
467 web service authentication method. If the parameter is not
468 specified or the empty string is specified it does not change the
469 authentication method, otherwise it is set to the specified value.
470 Using this parameter is a good measure against accidental
471 misconfiguration, as the web service ensures periodically that it
472 isn't changed.</para>
473 </listitem>
474
475 <listitem>
476 <para><computeroutput>--verbose</computeroutput> (or
477 <computeroutput>-v</computeroutput>): Normally, the web service
478 outputs only brief messages to the console each time a request is
479 served. With this option, the web service prints much more detailed
480 data about every request and the COM methods that those requests
481 are mapped to internally, which can be useful for debugging client
482 programs.</para>
483 </listitem>
484
485 <listitem>
486 <para><computeroutput>--pidfile</computeroutput> (or
487 <computeroutput>-P</computeroutput>): Name of the PID file which is
488 created when the daemon was started.</para>
489 </listitem>
490
491 <listitem>
492 <para><computeroutput>--logfile</computeroutput> (or
493 <computeroutput>-F</computeroutput>)
494 <computeroutput>&lt;file&gt;</computeroutput>: If this is
495 specified, the web service not only prints its output to the
496 console, but also writes it to the specified file. The file is
497 created if it does not exist; if it does exist, new output is
498 appended to it. This is useful if you run the web service
499 unattended and need to debug problems after they have
500 occurred.</para>
501 </listitem>
502
503 <listitem>
504 <para><computeroutput>--logrotate</computeroutput> (or
505 <computeroutput>-R</computeroutput>): Number of old log files to
506 keep, defaults to 10. Log rotation is disabled if set to 0.</para>
507 </listitem>
508
509 <listitem>
510 <para><computeroutput>--logsize</computeroutput> (or
511 <computeroutput>-S</computeroutput>): Maximum size of log file in
512 bytes, defaults to 100MB. Log rotation is triggered if the file
513 grows beyond this limit.</para>
514 </listitem>
515
516 <listitem>
517 <para><computeroutput>--loginterval</computeroutput> (or
518 <computeroutput>-I</computeroutput>): Maximum time interval to be
519 put in a log file before rotation is triggered, in seconds, and
520 defaults to one day.</para>
521 </listitem>
522 </itemizedlist>
523 </sect2>
524
525 <sect2 id="websrv_authenticate">
526 <title>Authenticating at web service logon</title>
527
528 <para>As opposed to the COM/XPCOM variant of the Main API, a client
529 that wants to use the web service must first log on by calling the
530 <link linkend="IWebsessionManager__logon">IWebsessionManager::logon()</link>
531 API that is specific to the
532 web service. Logon is necessary for the web service to be stateful;
533 internally, it maintains a session for each client that connects to
534 it.</para>
535
536 <para>The <computeroutput>IWebsessionManager::logon()</computeroutput>
537 API takes a user name and a password as arguments, which the web
538 service then passes to a customizable authentication plugin that
539 performs the actual authentication.</para>
540
541 <para>For testing purposes, it is recommended that you first disable
542 authentication with the command:
543 <screen>VBoxManage setproperty websrvauthlibrary null</screen></para>
544
545 <para><warning>
546 <para>This will cause all logons to succeed, regardless of user
547 name or password. This should of course not be used in a
548 production environment.</para>
549 </warning>Generally, the mechanism by which clients are
550 authenticated is configurable by way of the
551 <computeroutput>VBoxManage</computeroutput> command:</para>
552
553 <para><screen>VBoxManage setproperty websrvauthlibrary default|null|&lt;library&gt;</screen></para>
554
555 <para>This way you can specify any shared object/dynamic link module
556 that conforms with the specifications for VirtualBox external
557 authentication modules as laid out in section <emphasis
558 role="bold">VRDE authentication</emphasis> of the VirtualBox User
559 Guide; the web service uses the same kind of modules as the
560 VirtualBox VRDE server. For technical details on VirtualBox external
561 authentication modules see <xref linkend="vbox-auth"/></para>
562
563 <para>By default, after installation, the web service uses the
564 VBoxAuth module that ships with VirtualBox. This module uses PAM on
565 FreeBSD, Linux, and Solaris hosts to authenticate users. Any valid
566 username/password combination is accepted, it does not have to be the
567 username and password of the user running the web service daemon. If
568 <computeroutput>vboxwebsrv</computeroutput> doesn't run as root PAM
569 authentication can fail, because the
570 <computeroutput>/etc/shadow</computeroutput> file, which is used by PAM,
571 is only readable by root. On most Linux distributions PAM uses a suid
572 root helper internally, so make sure you test this before deploying it.
573 One can override authentication failures due to lack of read privileges
574 of the shadow password file by setting the environment variable
575 <computeroutput>VBOX_PAM_ALLOW_INACTIVE</computeroutput>.
576 Please use this variable carefully and only if you fully understand what
577 you're doing.</para>
578 </sect2>
579 </sect1>
580 </chapter>
581
582 <chapter>
583 <title>Environment-specific notes</title>
584
585 <para>The Main API described in <xref linkend="sdkref_classes"/> and
586 <xref linkend="sdkref_enums"/> is mostly identical in all the supported
587 programming environments which have been briefly mentioned in the
588 introduction of this book. As a result, the Main API's general concepts
589 described in <xref linkend="concepts"/> are the same whether you use the
590 object-oriented web service (OOWS) for JAX-WS or a raw web service
591 connection via, say, Perl, or whether you use C++ COM bindings.</para>
592
593 <para>Some things are different depending on your environment, however.
594 These differences are explained in this chapter.</para>
595
596 <sect1 id="glue">
597 <title>Using the object-oriented web service (OOWS)</title>
598
599 <para>As explained in <xref linkend="webservice-or-com"/>, VirtualBox
600 ships with client-side libraries for Java, Python and PHP that allow you
601 to use the VirtualBox web service in an intuitive, object-oriented way.
602 These libraries shield you from the client-side complications of managed
603 object references and other implementation details that come with the
604 VirtualBox web service. (If you are interested in these complications,
605 have a look at <xref linkend="raw-webservice"/>).</para>
606
607 <para>We recommend that you start your experiments with the VirtualBox
608 web service by using our object-oriented client libraries for JAX-WS, a
609 web service toolkit for Java, which enables you to write code to
610 interact with VirtualBox in the simplest manner possible.</para>
611
612 <para>As "interfaces", "attributes" and "methods" are COM concepts,
613 please read the documentation in <xref linkend="sdkref_classes"/> and
614 <xref linkend="sdkref_enums"/> with the following notes in mind.</para>
615
616 <para>The OOWS bindings attempt to map the Main API as closely as
617 possible to the Java, Python and PHP languages. In other words, objects
618 are objects, interfaces become classes, and you can call methods on
619 objects as you would on local objects.</para>
620
621 <para>The main difference remains with attributes: to read an attribute,
622 call a "getXXX" method, with "XXX" being the attribute name with a
623 capitalized first letter. So when the Main API Reference says that
624 <computeroutput>IMachine</computeroutput> has a "name" attribute (see
625 <link linkend="IMachine__name">IMachine::name</link>), call
626 <computeroutput>getName()</computeroutput> on an IMachine object to
627 obtain a machine's name. Unless the attribute is marked as read-only in
628 the documentation, there will also be a corresponding "set"
629 method.</para>
630
631 <sect2 id="glue-jax-ws">
632 <title>The object-oriented web service for JAX-WS</title>
633
634 <para>JAX-WS is a powerful toolkit by Sun Microsystems to build both
635 server and client code with Java. It is part of Java 6 (JDK 1.6), but
636 can also be obtained separately for Java 5 (JDK 1.5). The VirtualBox
637 SDK comes with precompiled OOWS bindings working with both Java 5 and
638 6.</para>
639
640 <para>The following sections explain how to get the JAX-WS sample code
641 running and explain a few common practices when using the JAX-WS
642 object-oriented web service.</para>
643
644 <sect3>
645 <title>Preparations</title>
646
647 <para>Since JAX-WS is already integrated into Java 6, no additional
648 preparations are needed for Java 6.</para>
649
650 <para>If you are using Java 5 (JDK 1.5.x), you will first need to
651 download and install an external JAX-WS implementation, as Java 5
652 does not support JAX-WS out of the box; for example, you can
653 download one from here: <ulink
654 url="https://jax-ws.dev.java.net/2.1.4/JAXWS2.1.4-20080502.jar">https://jax-ws.dev.java.net/2.1.4/JAXWS2.1.4-20080502.jar</ulink>.
655 Then perform the installation (<computeroutput>java -jar
656 JAXWS2.1.4-20080502.jar</computeroutput>).</para>
657 </sect3>
658
659 <sect3>
660 <title>Getting started: running the sample code</title>
661
662 <para>To run the OOWS for JAX-WS samples that we ship with the SDK,
663 perform the following steps: <orderedlist>
664 <listitem>
665 <para>Open a terminal and change to the directory where the
666 JAX-WS samples reside.<footnote>
667 <para>In
668 <computeroutput>sdk/bindings/glue/java/</computeroutput>.</para>
669 </footnote> Examine the header of
670 <computeroutput>Makefile</computeroutput> to see if the
671 supplied variables (Java compiler, Java executable) and a few
672 other details match your system settings.</para>
673 </listitem>
674
675 <listitem>
676 <para>To start the VirtualBox web service, open a second
677 terminal and change to the directory where the VirtualBox
678 executables are located. Then type:
679 <screen>./vboxwebsrv -v</screen></para>
680
681 <para>The web service now waits for connections and will run
682 until you press Ctrl+C in this second terminal. The -v
683 argument causes it to log all connections to the terminal.
684 (See <xref linkend="runvboxwebsrv"/> for details on how
685 to run the web service.)</para>
686 </listitem>
687
688 <listitem>
689 <para>Back in the first terminal and still in the samples
690 directory, to start a simple client example just type:
691 <screen>make run16</screen></para>
692
693 <para>if you're on a Java 6 system; on a Java 5 system, run
694 <computeroutput>make run15</computeroutput> instead.</para>
695
696 <para>This should work on all Unix-like systems such as Linux
697 and Solaris. For Windows systems, use commands similar to what
698 is used in the Makefile.</para>
699
700 <para>This will compile the
701 <computeroutput>clienttest.java</computeroutput> code on the
702 first call and then execute the resulting
703 <computeroutput>clienttest</computeroutput> class to show the
704 locally installed VMs (see below).</para>
705 </listitem>
706 </orderedlist></para>
707
708 <para>The <computeroutput>clienttest</computeroutput> sample
709 imitates a few typical command line tasks that
710 <computeroutput>VBoxManage</computeroutput>, VirtualBox's regular
711 command-line front-end, would provide (see the VirtualBox User
712 Guide for details). In particular, you can run:<itemizedlist>
713 <listitem>
714 <para><computeroutput>java clienttest show
715 vms</computeroutput>: show the virtual machines that are
716 registered locally.</para>
717 </listitem>
718
719 <listitem>
720 <para><computeroutput>java clienttest list
721 hostinfo</computeroutput>: show various information about the
722 host this VirtualBox installation runs on.</para>
723 </listitem>
724
725 <listitem>
726 <para><computeroutput>java clienttest startvm
727 &lt;vmname|uuid&gt;</computeroutput>: start the given virtual
728 machine.</para>
729 </listitem>
730 </itemizedlist></para>
731
732 <para>The <computeroutput>clienttest.java</computeroutput> sample
733 code illustrates common basic practices how to use the VirtualBox
734 OOWS for JAX-WS, which we will explain in more detail in the
735 following chapters.</para>
736 </sect3>
737
738 <sect3>
739 <title>Logging on to the web service</title>
740
741 <para>Before a web service client can do anything useful, two
742 objects need to be created, as can be seen in the
743 <computeroutput>clienttest</computeroutput> constructor:<orderedlist>
744 <listitem>
745 <para>An instance of
746 <link linkend="IWebsessionManager">IWebsessionManager</link>,
747 which is an interface provided by the web service to manage
748 "web sessions" -- that is, stateful connections to the web
749 service with persistent objects upon which methods can be
750 invoked.</para>
751
752 <para>In the OOWS for JAX-WS, the IWebsessionManager class
753 must be constructed explicitly, and a URL must be provided in
754 the constructor that specifies where the web service (the
755 server) awaits connections. The code in
756 <computeroutput>clienttest.java</computeroutput> connects to
757 "http://localhost:18083/", which is the default.</para>
758
759 <para>The port number, by default 18083, must match the port
760 number given to the
761 <computeroutput>vboxwebsrv</computeroutput> command line; see
762 <xref linkend="vboxwebsrv-ref"/>.</para>
763 </listitem>
764
765 <listitem>
766 <para>After that, the code calls
767 <link linkend="IWebsessionManager__logon">IWebsessionManager::logon()</link>,
768 which is the first call that actually communicates with the
769 server. This authenticates the client with the web service and
770 returns an instance of
771 <link linkend="IVirtualBox">IVirtualBox</link>,
772 the most fundamental interface of the VirtualBox web service,
773 from which all other functionality can be derived.</para>
774
775 <para>If logon doesn't work, please take another look at <xref
776 linkend="websrv_authenticate"/>.</para>
777 </listitem>
778 </orderedlist></para>
779 </sect3>
780
781 <sect3>
782 <title>Object management</title>
783
784 <para>The current OOWS for JAX-WS has certain memory management
785 related limitations. When you no longer need an object, call its
786 <link linkend="IManagedObjectRef__release">IManagedObjectRef::release()</link>
787 method explicitly, which
788 frees appropriate managed reference, as is required by the raw
789 web service; see <xref linkend="managed-object-references"/> for
790 details. This limitation may be reconsidered in a future version of
791 the VirtualBox SDK.</para>
792 </sect3>
793 </sect2>
794
795 <sect2 id="glue-python-ws">
796 <title>The object-oriented web service for Python</title>
797
798 <para>VirtualBox comes with two flavors of a Python API: one for web
799 service, discussed here, and one for the COM/XPCOM API discussed in
800 <xref linkend="pycom"/>. The client code is mostly similar, except
801 for the initialization part, so it is up to the application developer
802 to choose the appropriate technology. Moreover, a common Python glue
803 layer exists, abstracting out concrete platform access details, see
804 <xref linkend="glue-python"/>.</para>
805
806 <para>The minimum supported Python version is 2.6.</para>
807
808 <para>As indicated in <xref linkend="webservice-or-com"/>, the
809 COM/XPCOM API gives better performance without the SOAP overhead, and
810 does not require a web server to be running. On the other hand, the
811 COM/XPCOM Python API requires a suitable Python bridge for your Python
812 installation (VirtualBox ships the most important ones for each
813 platform<footnote>
814 <para>On Mac OS X only the Python versions bundled with the OS
815 are officially supported.</para>
816 </footnote>). On Windows, you can use the Main API from Python if the
817 Win32 extensions package for Python<footnote>
818 <para>See <ulink
819 url="http://sourceforge.net/project/showfiles.php?group_id=78018">http://sourceforge.net/project/showfiles.php?group_id=78018</ulink>.</para>
820 </footnote> is installed. Versions of Python Win32 extensions earlier
821 than 2.16 are known to have bugs, leading to issues with VirtualBox
822 Python bindings, so please make sure to use latest available Python
823 and Win32 extensions.</para>
824
825 <para>The VirtualBox OOWS for Python relies on the Python ZSI SOAP
826 implementation (see <ulink
827 url="http://pywebsvcs.sourceforge.net/zsi.html">http://pywebsvcs.sourceforge.net/zsi.html</ulink>),
828 which you will need to install locally before trying the examples.
829 Most Linux distributions come with a package for ZSI, such as
830 <computeroutput>python-zsi</computeroutput> in Ubuntu.</para>
831
832 <para>To get started, open a terminal and change to the
833 <computeroutput>sdk/bindings/glue/python/sample</computeroutput>
834 directory, which contains an example of a simple interactive shell
835 able to control a VirtualBox instance. The shell is written using the
836 API layer, thereby hiding different implementation details, so it is
837 actually an example of code shared among XPCOM, MSCOM and web services.
838 If you are interested in how to interact with the web services layer
839 directly, have a look at
840 <computeroutput>install/vboxapi/__init__.py</computeroutput> which
841 contains the glue layer for all target platforms (i.e. XPCOM, MSCOM
842 and web services).</para>
843
844 <para>To start the shell, run the following commands:
845 <screen>/opt/VirtualBox/vboxwebsrv -t 0 # start web service with object autocollection disabled
846export VBOX_PROGRAM_PATH=/opt/VirtualBox # your VirtualBox installation directory
847export VBOX_SDK_PATH=/home/youruser/vbox-sdk # where you've extracted the SDK
848./vboxshell.py -w </screen>
849 See <xref linkend="vboxshell"/> for more
850 details on the shell's functionality. For you, as a VirtualBox
851 application developer, the vboxshell sample could be interesting as an
852 example of how to write code targeting both local and remote cases
853 (COM/XPCOM and SOAP). The common part of the shell is the same -- the
854 only difference is how it interacts with the invocation layer. You can
855 use the <computeroutput>connect</computeroutput> shell command to
856 connect to remote VirtualBox servers; in this case you can skip
857 starting the local web server.</para>
858 </sect2>
859
860 <sect2>
861 <title>The object-oriented web service for PHP</title>
862
863 <para>VirtualBox also comes with object-oriented web service (OOWS)
864 wrappers for PHP5. These wrappers rely on the PHP SOAP
865 Extension<footnote>
866 <para>See
867 <ulink url="https://www.php.net/soap">https://www.php.net/soap</ulink>.</para>
868 </footnote>, which can be installed by configuring PHP with
869 <computeroutput>--enable-soap</computeroutput>.</para>
870 </sect2>
871 </sect1>
872
873 <sect1 id="raw-webservice">
874 <title>Using the raw web service with any language</title>
875
876 <para>The following examples show you how to use the raw web service,
877 without the object-oriented client-side code that was described in the
878 previous chapter.</para>
879
880 <para>Due to the limitations of SOAP and WSDL outlined in
881 <xref linkend="rawws-conventions"/>, keep the following notes in
882 mind when reading the documentation in <xref linkend="sdkref_classes"/>
883 and <xref linkend="sdkref_enums"/>:</para>
884
885 <para><orderedlist>
886 <listitem>
887 <para>Any COM method call becomes a <emphasis role="bold">plain
888 function call</emphasis> in the raw web service, with the object
889 as an additional first parameter (before the "real" parameters
890 listed in the documentation). So when the documentation says that
891 the <computeroutput>IVirtualBox</computeroutput> interface
892 supports the <computeroutput>createMachine()</computeroutput>
893 method (see
894 <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>),
895 the web service operation is
896 <computeroutput>IVirtualBox_createMachine(...)</computeroutput>,
897 and a managed object reference to an
898 <computeroutput>IVirtualBox</computeroutput> object must be passed
899 as the first argument.</para>
900 </listitem>
901
902 <listitem>
903 <para>For <emphasis role="bold">attributes</emphasis> in
904 interfaces, there will be at least one "get" function; there will
905 also be a "set" function, unless the attribute is "readonly". The
906 attribute name will be appended to the "get" or "set" prefix, with
907 a capitalized first letter. So, the "version" readonly attribute
908 of the <computeroutput>IVirtualBox</computeroutput> interface can
909 be retrieved by calling
910 <computeroutput>IVirtualBox_getVersion(vbox)</computeroutput>,
911 with <computeroutput>vbox</computeroutput> being the VirtualBox
912 object.</para>
913 </listitem>
914
915 <listitem>
916 <para>Whenever the API documentation says that a method (or an
917 attribute getter) returns an <emphasis
918 role="bold">object</emphasis>, it will returned a managed object
919 reference in the web service instead. As said above, managed
920 object references should be released if the web service client
921 does not log off again immediately!</para>
922 </listitem>
923 </orderedlist></para>
924
925 <para></para>
926
927 <sect2 id="webservice-java-sample">
928 <title>Raw web service example for Java with Axis</title>
929
930 <para>Axis is an older web service toolkit created by the Apache
931 foundation. If your distribution does not have it installed, you can
932 get a binary from <ulink
933 url="http://axis.apache.org">http://axis.apache.org</ulink>. The
934 following examples assume that you have Axis 1.4 installed.</para>
935
936 <para>The VirtualBox SDK ships with an example for Axis that, again,
937 is called <computeroutput>clienttest.java</computeroutput> and that
938 imitates a few <computeroutput>VBoxManage</computeroutput> commands
939 and sends them to the VirtualBox web service.</para>
940
941 <para>To try out the raw web service with Axis complete the following
942 steps:<orderedlist>
943 <listitem>
944 <para>Create a working directory somewhere. Under your
945 VirtualBox installation directory, find the
946 <computeroutput>sdk/webservice/samples/java/axis/</computeroutput>
947 directory and copy the file
948 <computeroutput>clienttest.java</computeroutput> to your working
949 directory.</para>
950 </listitem>
951
952 <listitem>
953 <para>Open a terminal in your working directory. Execute the
954 following command:
955 <screen>java org.apache.axis.wsdl.WSDL2Java /path/to/vboxwebService.wsdl</screen></para>
956
957 <para>The <computeroutput>vboxwebService.wsdl</computeroutput>
958 file should be located in the
959 <computeroutput>sdk/webservice/</computeroutput>
960 directory.</para>
961
962 <para>If this fails, your Apache Axis may not be located on your
963 system classpath, and you may have to adjust the CLASSPATH
964 environment variable. Something like this:
965 <screen>export CLASSPATH="/path-to-axis-1_4/lib/*":$CLASSPATH</screen></para>
966
967 <para>Use the directory where the Axis JAR files are located.
968 Mind the quotes so that your shell passes the "*" character to
969 the java executable without expanding. Alternatively, add a
970 corresponding <computeroutput>-classpath</computeroutput>
971 argument to the "java" call above.</para>
972
973 <para>If the command executes successfully, you should see an
974 "org" directory with subdirectories containing Java source files
975 in your working directory. These classes represent the
976 interfaces that the VirtualBox web service offers, as described
977 by the WSDL file.</para>
978
979 <para>This is the bit that makes using web services so
980 attractive to client developers: if a language's toolkit
981 understands WSDL, it can generate large amounts of support code
982 automatically. Clients can then easily use this support code and
983 can be done with just a few lines of code.</para>
984 </listitem>
985
986 <listitem>
987 <para>Next, compile the
988 <computeroutput>clienttest.java</computeroutput>
989 source:<screen>javac clienttest.java </screen></para>
990
991 <para>This should yield a "clienttest.class" file.</para>
992 </listitem>
993
994 <listitem>
995 <para>To start the VirtualBox web service, open a second
996 terminal and change to the directory where the VirtualBox
997 executables are located. Then type:
998 <screen>./vboxwebsrv -v</screen></para>
999
1000 <para>The web service now waits for connections and will run
1001 until you press Ctrl+C in this second terminal. The -v argument
1002 causes it to log all connections to the terminal. (See <xref
1003 linkend="runvboxwebsrv"/> for details on how to run the
1004 web service.)</para>
1005 </listitem>
1006
1007 <listitem>
1008 <para>Back in the original terminal where you compiled the Java
1009 source, run the resulting binary, which will then connect to the
1010 web service:<screen>java clienttest</screen></para>
1011
1012 <para>The client sample will connect to the web service (on
1013 localhost, but the code could be changed to connect remotely if
1014 the web service was running on a different machine) and make a
1015 number of method calls. It will output the version number of
1016 your VirtualBox installation and a list of all virtual machines
1017 that are currently registered (with a bit of seemingly random
1018 data, which will be explained later).</para>
1019 </listitem>
1020 </orderedlist></para>
1021 </sect2>
1022
1023 <sect2 id="raw-webservice-perl">
1024 <title>Raw web service example for Perl</title>
1025
1026 <para>We also ship a small sample for Perl. It uses the SOAP::Lite
1027 perl module to communicate with the VirtualBox web service.</para>
1028
1029 <para>The
1030 <computeroutput>sdk/bindings/webservice/perl/lib/</computeroutput>
1031 directory contains a pre-generated Perl module that allows for
1032 communicating with the web service from Perl. You can generate such a
1033 module yourself using the "stubmaker" tool that comes with SOAP::Lite,
1034 but since that tool is slow as well as sometimes unreliable, we ship a
1035 working module with the SDK for your convenience.</para>
1036
1037 <para>Perform the following steps:<orderedlist>
1038 <listitem>
1039 <para>If SOAP::Lite is not yet installed on your system, you
1040 will need to install the package first. On Debian-based systems,
1041 the package is called
1042 <computeroutput>libsoap-lite-perl</computeroutput>; on Gentoo,
1043 it's <computeroutput>dev-perl/SOAP-Lite</computeroutput>.</para>
1044 </listitem>
1045
1046 <listitem>
1047 <para>Open a terminal in the
1048 <computeroutput>sdk/bindings/webservice/perl/samples/</computeroutput>
1049 directory.</para>
1050 </listitem>
1051
1052 <listitem>
1053 <para>To start the VirtualBox web service, open a second
1054 terminal and change to the directory where the VirtualBox
1055 executables are located. Then type:
1056 <screen>./vboxwebsrv -v</screen></para>
1057
1058 <para>The web service now waits for connections and will run
1059 until you press Ctrl+C in this second terminal. The -v argument
1060 causes it to log all connections to the terminal. (See <xref
1061 linkend="runvboxwebsrv"/> for details on how to run the
1062 web service.)</para>
1063 </listitem>
1064
1065 <listitem>
1066 <para>In the first terminal with the Perl sample, run the
1067 clienttest.pl script:
1068 <screen>perl -I ../lib clienttest.pl</screen></para>
1069 </listitem>
1070 </orderedlist></para>
1071 </sect2>
1072
1073 <sect2>
1074 <title>Programming considerations for the raw web service</title>
1075
1076 <para>If you use the raw web service, you need to keep a number of
1077 things in mind, or you will sooner or later run into issues that are
1078 not immediately obvious. By contrast, the object-oriented client-side
1079 libraries described in <xref linkend="glue"/> take care of these
1080 things automatically and thus greatly simplify using the web
1081 service.</para>
1082
1083 <sect3 id="rawws-conventions">
1084 <title>Fundamental conventions</title>
1085
1086 <para>If you are familiar with other web services, you may find that the
1087 VirtualBox web service behaves a bit differently to accommodate
1088 for the fact that the VirtualBox web service more or less maps the
1089 VirtualBox Main COM API. The primary challenges in mapping the VirtualBox
1090 Main COM API to the web service are as follows:<itemizedlist>
1091 <listitem>
1092 <para>Web services, as expressed by WSDL, are not
1093 object-oriented. Even worse, they are normally stateless (or,
1094 in web services terminology, "loosely coupled"). Web service
1095 operations are entirely procedural, and one cannot normally
1096 make assumptions about the state of a web service between
1097 function calls.</para>
1098
1099 <para>In particular, this normally means that you cannot work
1100 on objects in one method call that were created by another
1101 call.</para>
1102 </listitem>
1103
1104 <listitem>
1105 <para>By contrast, the VirtualBox Main API, being expressed in
1106 COM, is object-oriented and works entirely on objects, which
1107 are grouped into public interfaces, which in turn have
1108 attributes and methods associated with them.</para>
1109 </listitem>
1110 </itemizedlist> For the VirtualBox web service, this results in
1111 three fundamental conventions:<orderedlist>
1112 <listitem>
1113 <para>All <emphasis role="bold">function names</emphasis> in
1114 the VirtualBox web service consist of an interface name and a
1115 method name, joined together by an underscore. This is because
1116 there are only functions ("operations") in WSDL, but no
1117 classes, interfaces, or methods.</para>
1118 </listitem>
1119
1120 <listitem>
1121 <para>All calls to the VirtualBox web service (except for logon, see
1122 below) take a <emphasis role="bold">managed object reference</emphasis>
1123 as the first argument, representing the object upon which the underlying
1124 method is invoked. (Managed object references are explained in detail
1125 below; see <xref linkend="managed-object-references"/>.)</para>
1126
1127 <para>So, when one would normally code, in the pseudo-code of
1128 an object-oriented language, to invoke a method upon an
1129 object:<screen>IMachine machine;
1130result = machine.getName();</screen></para>
1131
1132 <para>In the VirtualBox web service, this looks something like
1133 this (again, pseudo-code):<screen>IMachineRef machine;
1134result = IMachine_getName(machine);</screen></para>
1135 </listitem>
1136
1137 <listitem>
1138 <para>To make the web service stateful, and objects persistent
1139 between method calls, the VirtualBox web service introduces a
1140 <emphasis role="bold">session manager</emphasis> (by way of the
1141 <link linkend="IWebsessionManager">IWebsessionManager</link>
1142 interface), which manages object references. Any client wishing
1143 to interact with the web service must first log on to the
1144 session manager and in turn receives a managed object reference
1145 to an object that supports the
1146 <link linkend="IVirtualBox">IVirtualBox</link>
1147 interface (the basic interface in the Main API).</para>
1148 </listitem>
1149 </orderedlist></para>
1150
1151 <para>In other words, as opposed to other web services, <emphasis
1152 role="bold">the VirtualBox web service is both object-oriented and
1153 stateful.</emphasis></para>
1154 </sect3>
1155
1156 <sect3>
1157 <title>Example: A typical web service client session</title>
1158
1159 <para>A typical short web service session to retrieve the version
1160 number of the VirtualBox web service (to be precise, the underlying
1161 Main API version number) looks like this:<orderedlist>
1162 <listitem>
1163 <para>A client logs on to the web service by calling
1164 <link linkend="IWebsessionManager__logon">IWebsessionManager::logon()</link>
1165 with a valid user name and password. See
1166 <xref linkend="websrv_authenticate"/>
1167 for details about how authentication works.</para>
1168 </listitem>
1169
1170 <listitem>
1171 <para>On the server side,
1172 <computeroutput>vboxwebsrv</computeroutput> creates a session,
1173 which persists until the client calls
1174 <link linkend="IWebsessionManager__logoff">IWebsessionManager::logoff()</link>
1175 or the session times out after a configurable period of
1176 inactivity (see <xref linkend="vboxwebsrv-ref"/>).</para>
1177
1178 <para>For the new session, the web service creates an instance
1179 of <link linkend="IVirtualBox">IVirtualBox</link>.
1180 This interface is the most central one in the Main API and
1181 allows access to all other interfaces, either through
1182 attributes or method calls. For example, IVirtualBox contains
1183 a list of all virtual machines that are currently registered
1184 (as they would be listed on the left side of the VirtualBox
1185 main program).</para>
1186
1187 <para>The web service then creates a managed object reference
1188 for this instance of IVirtualBox and returns it to the calling
1189 client, which receives it as the return value of the logon
1190 call. Something like this:</para>
1191
1192 <screen>string oVirtualBox;
1193oVirtualBox = webservice.IWebsessionManager_logon("user", "pass");</screen>
1194
1195 <para>(The managed object reference "oVirtualBox" is just a
1196 string consisting of digits and dashes. However, it is a
1197 string with a meaning and will be checked by the web service.
1198 For details, see below. As hinted above,
1199 <link linkend="IWebsessionManager__logon">IWebsessionManager::logon()</link>
1200 is the <emphasis>only</emphasis> operation provided by the web
1201 service which does not take a managed object reference as the
1202 first argument!)</para>
1203 </listitem>
1204
1205 <listitem>
1206 <para>The VirtualBox Main API documentation explains that the
1207 <computeroutput>IVirtualBox</computeroutput> interface has a
1208 <link linkend="IVirtualBox__version">version</link>
1209 attribute, which is a string. For each attribute, there is a
1210 "get" and a "set" method in COM, which maps to the corresponding
1211 operations in the web service. So, to retrieve the "version"
1212 attribute of this <computeroutput>IVirtualBox</computeroutput>
1213 object, the web service client does this:
1214 <screen>string version;
1215version = webservice.IVirtualBox_getVersion(oVirtualBox);
1216
1217print version;</screen></para>
1218
1219 <para>And it will print
1220 "&VBOX_VERSION_MAJOR;.&VBOX_VERSION_MINOR;.&VBOX_VERSION_BUILD;".</para>
1221 </listitem>
1222
1223 <listitem>
1224 <para>The web service client calls
1225 <link linkend="IWebsessionManager__logoff">IWebsessionManager::logoff()</link>
1226 with the VirtualBox managed object reference. This will clean
1227 up all allocated resources.</para>
1228 </listitem>
1229 </orderedlist></para>
1230 </sect3>
1231
1232 <sect3 id="managed-object-references">
1233 <title>Managed object references</title>
1234
1235 <para>To a web service client, a managed object reference looks like
1236 a string: two 64-bit hex numbers separated by a dash. This string,
1237 however, represents a COM object that "lives" in the web service
1238 process. The two 64-bit numbers encoded in the managed object
1239 reference represent a session ID (which is the same for all objects
1240 in the same web service session, i.e. for all objects after one
1241 logon) and a unique object ID within that session.</para>
1242
1243 <para>Managed object references are created in two
1244 situations:<orderedlist>
1245 <listitem>
1246 <para>When a client logs on, by calling
1247 <link linkend="IWebsessionManager__logon">IWebsessionManager::logon()</link>.</para>
1248
1249 <para>Upon logon, the websession manager creates one instance
1250 of <link linkend="IVirtualBox">IVirtualBox</link>,
1251 which can be used for directly performing calls to its
1252 methods, or used as a parameter for calling some methods of
1253 <link linkend="IWebsessionManager">IWebsessionManager</link>.
1254 Creating Main API session objects is performed using
1255 <link linkend="IWebsessionManager__getSessionObject">IWebsessionManager::getSessionObject()</link>.</para>
1256
1257 <para>(Technically, there is always only one
1258 <link linkend="IVirtualBox">IVirtualBox</link> object, which
1259 is shared between all websessions and clients, as it is a COM
1260 singleton. However, each session receives its own managed
1261 object reference to it.)</para>
1262 </listitem>
1263
1264 <listitem>
1265 <para>Whenever a web service clients invokes an operation
1266 whose COM implementation creates COM objects.</para>
1267
1268 <para>For example,
1269 <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
1270 creates a new instance of
1271 <link linkend="IMachine">IMachine</link>;
1272 the COM object returned by the COM method call is then wrapped
1273 into a managed object reference by the web server, and this
1274 reference is returned to the web service client.</para>
1275 </listitem>
1276 </orderedlist></para>
1277
1278 <para>Internally, in the web service process, each managed object
1279 reference is simply a small data structure, containing a COM pointer
1280 to the "real" COM object, the web session ID and the object ID. This
1281 structure is allocated on creation and stored efficiently in hashes,
1282 so that the web service can look up the COM object quickly whenever
1283 a web service client wishes to make a method call. The random
1284 session ID also ensures that one web service client cannot intercept
1285 the objects of another.</para>
1286
1287 <para>Managed object references are not destroyed automatically and
1288 must be released by explicitly calling
1289 <link linkend="IManagedObjectRef__release">IManagedObjectRef::release()</link>.
1290 This is important, as
1291 otherwise hundreds or thousands of managed object references (and
1292 corresponding COM objects, which can consume much more memory!) can
1293 pile up in the web service process and eventually cause it to deny
1294 service.</para>
1295
1296 <para>To reiterate: The underlying COM object, which the reference
1297 points to, is only freed if the managed object reference is
1298 released. It is therefore vital that web service clients properly
1299 clean up after the managed object references that are returned to
1300 them.</para>
1301
1302 <para>When a web service client calls
1303 <link linkend="IWebsessionManager__logoff">IWebsessionManager::logoff()</link>,
1304 all managed object references created during the session are
1305 automatically freed. For short-lived sessions that do not create a
1306 lot of objects, logging off may therefore be sufficient, although it
1307 is certainly not "best practice".</para>
1308 </sect3>
1309
1310 <sect3>
1311 <title>Some more detail about web service operation</title>
1312
1313 <sect4 id="soap">
1314 <title>SOAP messages</title>
1315
1316 <para>Whenever a client makes a call to a web service, this
1317 involves a complicated procedure internally. These calls are
1318 remote procedure calls. Each such procedure call typically
1319 consists of two "message" being passed, where each message is a
1320 plain-text HTTP request with a standard HTTP header and a special
1321 XML document following. This XML document encodes the name of the
1322 procedure to call and the argument names and values passed to
1323 it.</para>
1324
1325 <para>To give you an idea of what such a message looks like,
1326 assuming that a web service provides a procedure called
1327 "SayHello", which takes a string "name" as an argument and returns
1328 "Hello" with a space and that name appended, the request message
1329 could look like this:</para>
1330
1331 <para><screen>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
1332&lt;SOAP-ENV:Envelope
1333 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
1334 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
1335 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1336 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
1337 xmlns:test="http://test/"&gt;
1338&lt;SOAP-ENV:Body&gt;
1339 &lt;test:SayHello&gt;
1340 &lt;name&gt;Peter&lt;/name&gt;
1341 &lt;/test:SayHello&gt;
1342 &lt;/SOAP-ENV:Body&gt;
1343&lt;/SOAP-ENV:Envelope&gt;</screen>A similar message -- the "response" message
1344 -- would be sent back from the web service to the client,
1345 containing the return value "Hello Peter".</para>
1346
1347 <para>Most programming languages provide automatic support to
1348 generate such messages whenever code in that programming language
1349 makes such a request. In other words, these programming languages
1350 allow for writing something like this (in pseudo-C++ code):</para>
1351
1352 <para><screen>webServiceClass service("localhost", 18083); // server and port
1353string result = service.SayHello("Peter"); // invoke remote procedure</screen>
1354 and would, for these two pseudo-lines, automatically perform these
1355 steps:</para>
1356
1357 <para><orderedlist>
1358 <listitem>
1359 <para>Prepare a connection to the web service running on port
1360 18083 of "localhost".</para>
1361 </listitem>
1362
1363 <listitem>
1364 <para>Generate a SOAP message similar to the above example for the
1365 <computeroutput>SayHello()</computeroutput> function of the web service
1366 by encoding all arguments of the remote procedure call (which could
1367 involve all kinds of type conversions and complex marshalling for arrays
1368 and structures).</para>
1369 </listitem>
1370
1371 <listitem>
1372 <para>Connect to the web service via HTTP and then send that
1373 message.</para>
1374 </listitem>
1375
1376 <listitem>
1377 <para>Wait for the web service to send a response message.</para>
1378 </listitem>
1379
1380 <listitem>
1381 <para>Decode that response message and put the return value
1382 of the remote procedure into the "result" variable.</para>
1383 </listitem>
1384 </orderedlist></para>
1385 </sect4>
1386
1387 <sect4 id="wsdl">
1388 <title>Service descriptions in WSDL</title>
1389
1390 <para>In the above explanations about SOAP, it wasn't explained how
1391 the programming language learns about how to translate function
1392 calls in its own syntax into proper SOAP messages. In other words,
1393 the programming language needs to know what operations the web
1394 service supports and what types of arguments are required for the
1395 operation's data in order to be able to properly serialize and
1396 deserialize the data to and from the web service. For example, if
1397 a web service operation expects a number in "double" floating
1398 point format for a particular parameter, the programming language
1399 cannot send it a string instead.</para>
1400
1401 <para>For this, the Web Service Definition Language (WSDL) was
1402 invented, another XML substandard that describes exactly what
1403 operations the web service supports and, for each operation, which
1404 parameters and types are needed with each request and response
1405 message. WSDL descriptions can be incredibly verbose, and one of
1406 the few good things that can be said about this standard is that
1407 it is indeed supported by most programming languages.</para>
1408
1409 <para>So, if it is said that a programming language "supports" web
1410 services, this typically means that a programming language has
1411 support for parsing WSDL files and somehow integrating the remote
1412 procedure calls into the native language syntax -- for example, as
1413 shown in the Java sample in <xref
1414 linkend="webservice-java-sample"/>.</para>
1415
1416 <para>For details about how programming languages support web
1417 services, please refer to the documentation that comes with the
1418 individual language. Here are a few pointers:</para>
1419
1420 <orderedlist>
1421 <listitem>
1422 <para>For <emphasis role="bold">C++, </emphasis> among many
1423 others, the gSOAP toolkit is a good option. Parts of gSOAP are
1424 also used in VirtualBox to implement the VirtualBox web
1425 service.</para>
1426 </listitem>
1427
1428 <listitem>
1429 <para>For <emphasis role="bold">Java, </emphasis> there are
1430 several implementations already described in this document
1431 (see <xref linkend="glue-jax-ws"/> and <xref
1432 linkend="webservice-java-sample"/>).</para>
1433 </listitem>
1434
1435 <listitem>
1436 <para><emphasis role="bold">Perl</emphasis> supports WSDL via
1437 the SOAP::Lite package. This in turn comes with a tool called
1438 <computeroutput>stubmaker.pl</computeroutput> that allows you
1439 to turn any WSDL file into a Perl package that you can import.
1440 (You can also import any WSDL file "live" by having it parsed
1441 every time the script runs, but that can take a while.) You
1442 can then code (again, assuming the above example):
1443 <screen>my $result = servicename-&gt;sayHello("Peter");</screen>
1444 </para>
1445
1446 <para>A sample that uses SOAP::Lite was described in <xref
1447 linkend="raw-webservice-perl"/>.</para>
1448 </listitem>
1449 </orderedlist>
1450 </sect4>
1451 </sect3>
1452 </sect2>
1453 </sect1>
1454
1455 <sect1 id="api_com">
1456 <title>Using COM/XPCOM directly</title>
1457
1458 <para>If you do not require <emphasis>remote</emphasis> procedure calls
1459 such as those offered by the VirtualBox web service, and if you know
1460 Python or C++ as well as COM, you might find it preferable to program
1461 VirtualBox's Main API directly via COM.</para>
1462
1463 <para>COM stands for "Component Object Model" and is a standard
1464 originally introduced by Microsoft in the 1990s for Microsoft Windows.
1465 It allows for organizing software in an object-oriented way and across
1466 processes; code in one process may access objects that live in another
1467 process.</para>
1468
1469 <para>COM has several advantages: it is language-neutral, meaning that
1470 even though all of VirtualBox is internally written in C++, programs
1471 written in other languages can communicate with it. COM also cleanly
1472 separates interface from implementation, so that external programs do
1473 not need to know anything about the messy and complicated details of
1474 VirtualBox internals.</para>
1475
1476 <para>On a Windows host, all parts of VirtualBox will use the COM
1477 functionality that is native to Windows. On other hosts (including
1478 Linux), VirtualBox comes with a built-in implementation of XPCOM, as
1479 originally created by the Mozilla project, which we have enhanced to
1480 support interprocess communication on a level comparable to Microsoft
1481 COM. Internally, VirtualBox has an abstraction layer that allows the
1482 same VirtualBox code to work both with native COM as well as our XPCOM
1483 implementation.</para>
1484
1485 <sect2 id="pycom">
1486 <title>Python COM API</title>
1487
1488 <para>On Windows, Python scripts can use COM and VirtualBox interfaces
1489 to control almost all aspects of virtual machine execution. For example,
1490 you can use the following commands to instantiate the VirtualBox object
1491 and start a VM: <screen>
1492 vbox = win32com.client.Dispatch("VirtualBox.VirtualBox")
1493 session = win32com.client.Dispatch("VirtualBox.Session")
1494 mach = vbox.findMachine("uuid or name of machine to start")
1495 progress = mach.launchVMProcess(session, "gui", "")
1496 progress.waitForCompletion(-1)
1497 </screen> Also, see
1498 <computeroutput>sdk/bindings/glue/python/samples/vboxshell.py</computeroutput>
1499 for more advanced usage scenarious. However, unless you have specific
1500 requirements, we strongly recommend that you use the generic glue layer
1501 described in the next section to access MS COM objects.</para>
1502 </sect2>
1503
1504 <sect2 id="glue-python">
1505 <title>Common Python bindings layer</title>
1506
1507 <para>As different wrappers ultimately provide access to the same
1508 underlying API, and to simplify porting and development of Python
1509 applications using the VirtualBox Main API, we developed a common glue
1510 layer that abstracts out most platform-specific details from the
1511 application and allows the developer to focus on application logic.
1512 The VirtualBox installer automatically sets up this glue layer for the
1513 system default Python installation.</para>
1514
1515 <para>See <xref linkend="glue-python-setup"/> for details on how to
1516 set up the glue layer if you want to use a different Python installation,
1517 or if the VirtualBox installer failed to detect and set it up accordingly.</para>
1518
1519 <para>The minimum supported Python version is 2.6.</para>
1520
1521 <para>In this layer, the class
1522 <computeroutput>VirtualBoxManager</computeroutput> hides most
1523 platform-specific details. It can be used to access both the local
1524 (COM) and the web service based API. The following code can be used by
1525 an application to use the glue layer.</para>
1526
1527 <screen># This code assumes vboxapi.py from VirtualBox distribution
1528# being in PYTHONPATH, or installed system-wide
1529from vboxapi import VirtualBoxManager
1530
1531# This code initializes VirtualBox manager with default style
1532# and parameters
1533virtualBoxManager = VirtualBoxManager(None, None)
1534
1535# Alternatively, one can be more verbose, and initialize
1536# glue with web service backend, and provide authentication
1537# information
1538virtualBoxManager = VirtualBoxManager("WEBSERVICE",
1539 {'url':'http://myhost.com::18083/',
1540 'user':'me',
1541 'password':'secret'}) </screen>
1542
1543 <para>We supply the <computeroutput>VirtualBoxManager</computeroutput>
1544 constructor with 2 arguments: style and parameters. Style defines
1545 which bindings style to use (could be "MSCOM", "XPCOM" or
1546 "WEBSERVICE"), and if set to <computeroutput>None</computeroutput>
1547 defaults to usable platform bindings (MS COM on Windows, XPCOM on
1548 other platforms). The second argument defines parameters, passed to
1549 the platform-specific module, as we do in the second example, where we
1550 pass a username and password to be used to authenticate against the web
1551 service.</para>
1552
1553 <para>After obtaining the
1554 <computeroutput>VirtualBoxManager</computeroutput> instance, one can
1555 perform operations on the IVirtualBox class. For example, the
1556 following code will a start virtual machine by name or ID:</para>
1557
1558 <screen>from vboxapi import VirtualBoxManager
1559mgr = VirtualBoxManager(None, None)
1560vbox = mgr.getVirtualBox()
1561name = "Linux"
1562mach = vbox.findMachine(name)
1563session = mgr.getSessionObject(vbox)
1564progress = mach.launchVMProcess(session, "gui", "")
1565progress.waitForCompletion(-1)
1566mgr.closeMachineSession(session)
1567 </screen>
1568 <para>
1569 The following code will print all registered machines and their log
1570 folders:
1571 </para>
1572 <screen>from vboxapi import VirtualBoxManager
1573mgr = VirtualBoxManager(None, None)
1574vbox = mgr.getVirtualBox()
1575
1576for m in mgr.getArray(vbox, 'machines'):
1577 print "Machine '%s' logs in '%s'" %(m.name, m.logFolder)
1578 </screen>
1579
1580 <para>The code above demonstrates cross-platform access to array
1581 properties (certain limitations prevent one from using
1582 <computeroutput>vbox.machines</computeroutput> to access a list of
1583 available virtual machines in the case of XPCOM), and a mechanism for
1584 uniform session creation and closure
1585 (<computeroutput>mgr.getSessionObject()</computeroutput>).</para>
1586
1587 <sect3 id="glue-python-setup">
1588 <title>Manual or subsequent setup</title>
1589
1590 <para>If you want to use the glue layer with a different Python
1591 installation or the installer failed to set it up, then use these steps
1592 in a shell to install the necessary files:</para>
1593
1594 <screen> # cd VBOX_INSTALL_PATH/sdk/installer
1595 # python vboxapisetup.py install</screen>
1596
1597 <note> <para>On Windows hosts, a Python distribution along with the
1598 win32api bindings package need to be installed as a prerequisite. </para></note>
1599 </sect3>
1600
1601 </sect2>
1602
1603 <sect2 id="cppcom">
1604 <title>C++ COM API</title>
1605
1606 <para>C++ is the language that VirtualBox itself is written in, so C++
1607 is the most direct way to use the Main API -- but it is not
1608 necessarily the easiest, as using COM and XPCOM has its own set of
1609 complications.</para>
1610
1611 <para>VirtualBox ships with sample programs that demonstrate how to
1612 use the Main API to implement a number of tasks on your host platform.
1613 These samples can be found in the
1614 <computeroutput>sdk/bindings/xpcom/samples</computeroutput> directory for
1615 Linux, Mac OS X and Solaris and
1616 <computeroutput>sdk/bindings/mscom/samples</computeroutput> for Windows.
1617 The two samples are actually different, because the one for Windows
1618 uses native COM, whereas the other uses our XPCOM implementation, as
1619 described above.</para>
1620
1621 <para>Since COM and XPCOM are conceptually very similar but vary in
1622 the implementation details, we have created a "glue" layer that
1623 shields COM client code from these differences. All VirtualBox uses is
1624 this glue layer, so the same code written once works on both Windows
1625 hosts (with native COM) as well as on other hosts (with our XPCOM
1626 implementation). It is recommended to always use this glue code
1627 instead of using the COM and XPCOM APIs directly, as it is very easy
1628 to make your code completely independent from the platform it is
1629 running on.<!-- A third sample,
1630 <computeroutput>tstVBoxAPIGlue.cpp</computeroutput>, illustrates how to
1631 use the glue layer.
1632--></para>
1633
1634 <para>In order to encapsulate platform differences between Microsoft
1635 COM and XPCOM, the following items should be kept in mind when using
1636 the glue layer:</para>
1637
1638 <para><orderedlist>
1639 <listitem>
1640 <para><emphasis role="bold">Attribute getters and
1641 setters.</emphasis> COM has the notion of "attributes" in
1642 interfaces, which roughly compare to C++ member variables in
1643 classes. The difference is that for each attribute declared in
1644 an interface, COM automatically provides a "get" method to
1645 return the attribute's value. Unless the attribute has been
1646 marked as "readonly", a "set" attribute is also provided.</para>
1647
1648 <para>To illustrate, the IVirtualBox interface has a "version"
1649 attribute, which is read-only and of the "wstring" type (the
1650 standard string type in COM). As a result, you can call the
1651 "get" method for this attribute to retrieve the version number
1652 of VirtualBox.</para>
1653
1654 <para>Unfortunately, the implementation differs between COM and
1655 XPCOM. Microsoft COM names the "get" method like this:
1656 <computeroutput>get_Attribute()</computeroutput>, whereas XPCOM
1657 uses this syntax:
1658 <computeroutput>GetAttribute()</computeroutput> (and accordingly
1659 for "set" methods). To hide these differences, the VirtualBox
1660 glue code provides the
1661 <computeroutput>COMGETTER(attrib)</computeroutput> and
1662 <computeroutput>COMSETTER(attrib)</computeroutput> macros. So,
1663 <computeroutput>COMGETTER(version)()</computeroutput> (note, two
1664 pairs of brackets) expands to
1665 <computeroutput>get_Version()</computeroutput> on Windows and
1666 <computeroutput>GetVersion()</computeroutput> on other
1667 platforms.</para>
1668 </listitem>
1669
1670 <listitem>
1671 <para><emphasis role="bold">Unicode conversions.</emphasis>
1672 While the rest of the modern world has pretty much settled on
1673 encoding strings in UTF-8, COM, unfortunately, uses UCS-16
1674 encoding. This requires a lot of conversions, in particular
1675 between the VirtualBox Main API and the Qt GUI, which, like the
1676 rest of Qt, likes to use UTF-8.</para>
1677
1678 <para>To facilitate these conversions, VirtualBox provides the
1679 <computeroutput>com::Bstr</computeroutput> and
1680 <computeroutput>com::Utf8Str</computeroutput> classes, which
1681 support all kinds of conversions back and forth.</para>
1682 </listitem>
1683
1684 <listitem>
1685 <para><emphasis role="bold">COM autopointers.</emphasis>
1686 Possibly the greatest pain of using COM -- reference counting --
1687 is alleviated by the
1688 <computeroutput>ComPtr&lt;&gt;</computeroutput> template
1689 provided by the <computeroutput>ptr.h</computeroutput> file in
1690 the glue layer.</para>
1691 </listitem>
1692 </orderedlist></para>
1693 </sect2>
1694
1695 <sect2 id="event-queue">
1696 <title>Event queue processing</title>
1697
1698 <para>Both VirtualBox client programs and front-ends should
1699 periodically perform processing of the main event queue, and do that
1700 on the application's main thread. In the case of a typical GUI
1701 Windows/Mac OS application this happens automatically in the GUI's
1702 dispatch loop. However, for CLI only application, the appropriate actions
1703 have to be taken. For C++ applications, the VirtualBox SDK provided glue
1704 method
1705 <screen>
1706 int EventQueue::processEventQueue(uint32_t cMsTimeout)
1707 </screen> can be used for both blocking and non-blocking operations.
1708 For the Python bindings, a common layer provides the method <screen>
1709 VirtualBoxManager.waitForEvents(ms)
1710 </screen> with similar semantics.</para>
1711
1712 <para>Things get somewhat more complicated for situations where an
1713 application using VirtualBox cannot directly control the main event
1714 loop and the main event queue is separated from the event queue of the
1715 programming library (for example in case of Qt on Unix platforms). In
1716 such a case, the application developer is advised to use a
1717 platform/toolkit specific event injection mechanism to force event
1718 queue checks either based on periodic timer events delivered to the
1719 main thread, or by using custom platform messages to notify the main
1720 thread when events are available. See the Qt (VirtualBox) front-end as
1721 an example.</para>
1722 </sect2>
1723
1724 <sect2 id="vbcom">
1725 <title>Visual Basic and Visual Basic Script (VBS) on Windows
1726 hosts</title>
1727
1728 <para>On Windows hosts, one can control some of the VirtualBox Main
1729 API functionality from VBS scripts, and pretty much everything from
1730 Visual Basic programs.<footnote>
1731 <para>The difference results from the way VBS treats COM
1732 safearrays, which are used to keep lists in the Main API. VBS
1733 expects every array element to be a
1734 <computeroutput>VARIANT</computeroutput>, which is too strict a
1735 limitation for any high performance API. We may lift this
1736 restriction for interface APIs in a future version, or
1737 alternatively provide conversion APIs.</para>
1738 </footnote></para>
1739
1740 <para>VBS is a scripting language available in any recent Windows
1741 environment. As an example, the following VBS code will print the
1742 VirtualBox version: <screen>
1743 set vb = CreateObject("VirtualBox.VirtualBox")
1744 Wscript.Echo "VirtualBox version " &amp; vb.version
1745 </screen> See
1746 <computeroutput>sdk/bindings/mscom/vbs/sample/vboxinfo.vbs</computeroutput>
1747 for the complete sample.</para>
1748
1749 <para>Visual Basic is a popular high level language capable of
1750 accessing COM objects. The following VB code will iterate over all
1751 available virtual machines:<screen>
1752 Dim vb As VirtualBox.IVirtualBox
1753
1754 vb = CreateObject("VirtualBox.VirtualBox")
1755 machines = ""
1756 For Each m In vb.Machines
1757 m = m &amp; " " &amp; m.Name
1758 Next
1759 </screen> See
1760 <computeroutput>sdk/bindings/mscom/vb/sample/vboxinfo.vb</computeroutput>
1761 for the complete sample.</para>
1762 </sect2>
1763
1764 <sect2 id="cbinding">
1765 <title>C bindings to the VirtualBox API</title>
1766
1767 <para>The VirtualBox API was originally designed to be object oriented
1768 and leverages XPCOM or COM as the middleware to natively map the API to
1769 C++. This means that in order to use the VirtualBox API from C there
1770 needs to be some helper code to bridge the language differences and
1771 reduce the differences between platforms.</para>
1772
1773 <sect3 id="capi_glue">
1774 <title>Cross-platform C bindings to the VirtualBox API</title>
1775
1776 <para>Starting with version 4.3, VirtualBox offers C bindings
1777 which allows using the same C client sources for all platforms,
1778 covering Windows, Linux, Mac OS X and Solaris. It is the
1779 preferred way to write API clients, even though the old style
1780 is still available.</para>
1781
1782 </sect3>
1783
1784 <sect3 id="c-gettingstarted">
1785 <title>Getting started</title>
1786
1787 <para>The following sections describe how to use the VirtualBox API
1788 in a C program. The necessary files are included in the SDK, in the
1789 directories <computeroutput>sdk/bindings/c/include</computeroutput>
1790 and <computeroutput>sdk/bindings/c/glue</computeroutput>.</para>
1791
1792 <para>As part of the SDK, a sample program
1793 <computeroutput>tstCAPIGlue.c</computeroutput> is provided in the
1794 directory <computeroutput>sdk/bindings/c/samples</computeroutput>
1795 which demonstrates
1796 using the C bindings to initialize the API, get handles for
1797 VirtualBox and Session objects, make calls to list and start virtual
1798 machines, monitor events, and uninitialize resources when done. The
1799 sample program is trying to illustrate all relevant concepts, so it
1800 is a great source of detail information. Among many other generally
1801 useful code sequences it contains a function which shows how to
1802 retrieve error details in C code if they are available from the API
1803 call.</para>
1804
1805 <para>The sample program <computeroutput>tstCAPIGlue</computeroutput>
1806 can be built using the provided
1807 <computeroutput>Makefile</computeroutput> and can be run without
1808 arguments.</para>
1809
1810 <para>It uses the VBoxCAPIGlue library (source code is in directory
1811 <computeroutput>sdk/bindings/c/glue</computeroutput>, to be used in
1812 your API client code) to open the C binding layer during runtime,
1813 which is preferred to other means as it isolates the code which
1814 locates the necessary dynamic library, using a known working way
1815 which works on all platforms. If you encounter problems with this
1816 glue code in <computeroutput>VBoxCAPIGlue.c</computeroutput>, let the
1817 VirtualBox developers know, rather than inventing incompatible
1818 solutions.</para>
1819
1820 <para>The following sections document the important concepts needed
1821 to correctly use the C bindings, as it is vital for developing API
1822 client code which manages memory correctly, updates the reference
1823 counters correctly, and avoids crashes and memory leaks. Often API
1824 clients need to handle events, so the C API specifics are also
1825 described below.</para>
1826 </sect3>
1827
1828 <sect3 id="c-initialization">
1829 <title>VirtualBox C API initialization</title>
1830
1831 <para>Just like in C++, the API and the underlying middleware needs
1832 to be initialized before it can be used. The
1833 <computeroutput>VBoxCAPI_v&VBOX_VERSION_MAJOR;_&VBOX_VERSION_MINOR;.h</computeroutput>
1834 header file provides the interface to the C bindings, but you can
1835 alternatively and more conveniently just include
1836 <computeroutput>VBoxCAPIGlue.h</computeroutput>,
1837 as this avoids the VirtualBox version dependent header file name and
1838 makes sure that the global variable <code>g_pVBoxFuncs</code> contains a
1839 pointer to the structure which contains the helper function pointers.
1840 Here's how to initialize the C API:<screen>#include "VBoxCAPIGlue.h"
1841...
1842IVirtualBoxClient *vboxclient = NULL;
1843
1844/*
1845 * VBoxCGlueInit() loads the necessary dynamic library, handles errors
1846 * (producing an error message hinting what went wrong) and gives you
1847 * the pointer to the function table (g_pVBoxFuncs).
1848 *
1849 * Once you get the function table, then how and which functions
1850 * to use is explained below.
1851 *
1852 * g_pVBoxFuncs-&gt;pfnClientInitialize does all the necessary startup
1853 * action and provides us with pointers to an IVirtualBoxClient instance.
1854 * It should be matched by a call to g_pVBoxFuncs-&gt;pfnClientUninitialize()
1855 * when done.
1856 */
1857
1858if (VBoxCGlueInit())
1859{
1860 fprintf(stderr, "s: FATAL: VBoxCGlueInit failed: %s\n",
1861 argv[0], g_szVBoxErrMsg);
1862 return EXIT_FAILURE;
1863}
1864
1865g_pVBoxFuncs-&gt;pfnClientInitialize(NULL, &amp;vboxclient);
1866if (!vboxclient)
1867{
1868 fprintf(stderr, "%s: FATAL: could not get VirtualBoxClient reference\n",
1869 argv[0]);
1870 return EXIT_FAILURE;
1871}</screen></para>
1872
1873 <para>If <computeroutput>vboxclient</computeroutput> is still
1874 <computeroutput>NULL</computeroutput> this means the initializationi
1875 failed and the VirtualBox C API cannot be used.</para>
1876
1877 <para>It is possible to write C applications using multiple threads
1878 which all use the VirtualBox API, as long as you're initializing
1879 the C API in each thread which your application creates. This is done
1880 with <code>g_pVBoxFuncs->pfnClientThreadInitialize()</code> and
1881 likewise before the thread is terminated the API must be
1882 uninitialized with
1883 <code>g_pVBoxFuncs->pfnClientThreadUninitialize()</code>. You don't
1884 have to use these functions in worker threads created by COM/XPCOM
1885 (which you might utilize if your code uses active event handling),
1886 since everything is initialized correctly already. On Windows the C
1887 bindings create a marshaller which supports a wide range of COM
1888 threading models, from Single-Threaded Apartments (STA) to
1889 Multithreaded Apartments (MTA), so you don't have to worry about
1890 these details unless you plan to use active event handlers. See
1891 the sample code for how to get this to work reliably (in other words
1892 think twice if passive event handling isn't the better solution after
1893 you looked at the sample code).</para>
1894 </sect3>
1895
1896 <sect3 id="c-invocation">
1897 <title>C API attribute and method invocation</title>
1898
1899 <para>Method invocation is straightforward. It looks very similar
1900 to the C++ mechanism since it also uses a macro which internally
1901 accesses the vtable and additionally needs to be passed a pointer to the
1902 object as the first argument to serve as the
1903 <computeroutput>this</computeroutput> pointer.</para>
1904
1905 <para>Using the C bindings all method invocations return a numeric
1906 result code of type <code>HRESULT</code> (with a few exceptions
1907 which normally are not relevant).</para>
1908
1909 <para>If an interface is specified as returning an object, a pointer
1910 to a pointer to the appropriate object must be passed as the last
1911 argument. The method will then store an object pointer in that
1912 location.</para>
1913
1914 <para>Likewise, attributes (properties) can be queried or set using
1915 method invocations, using specially named methods. For each
1916 attribute there exists a getter method, the name of which is composed
1917 of <computeroutput>get_</computeroutput> followed by the capitalized
1918 attribute name. Unless the attribute is read-only, an analogous
1919 <computeroutput>set_</computeroutput> method exists. Let's apply
1920 these rules to get the <computeroutput>IVirtualBox</computeroutput>
1921 reference, an <computeroutput>ISession</computeroutput> instance
1922 reference and read the
1923 <link linkend="IVirtualBox__revision">IVirtualBox::revision</link>
1924 attribute:
1925 <screen>
1926IVirtualBox *vbox = NULL;
1927ISession *session = NULL;
1928HRESULT rc;
1929ULONG revision;
1930
1931rc = IVirtualBoxClient_get_VirtualBox(vboxclient, &amp;vbox);
1932
1933if (FAILED(rc) || !vbox)
1934{
1935 PrintErrorInfo(argv[0], "FATAL: could not get VirtualBox reference", rc);
1936 return EXIT_FAILURE;
1937}
1938rc = IVirtualBoxClient_get_Session(vboxclient, &amp;session);
1939if (FAILED(rc) || !session)
1940{
1941 PrintErrorInfo(argv[0], "FATAL: could not get Session reference", rc);
1942 return EXIT_FAILURE;
1943}
1944
1945rc = IVirtualBox_get_Revision(vbox, &amp;revision);
1946if (SUCCEEDED(rc))
1947{
1948 printf("Revision: %u\n", revision);
1949}</screen></para>
1950
1951 <para>The convenience macros for calling a method are named by prepending
1952 the method name with the interface name (using <code>_</code> as the
1953 separator).</para>
1954
1955 <para>So far only attribute getters were illustrated, but generic
1956 method calls are straightforward, too:
1957 <screen>IMachine *machine = NULL;
1958BSTR vmname = ...;
1959...
1960/*
1961 * Calling IMachine::findMachine(...)
1962 */
1963rc = IVirtualBox_FindMachine(vbox, vmname, &amp;machine);</screen></para>
1964
1965 <para>As a more complicated example of a method invocation, let's
1966 call
1967 <link linkend="IMachine__launchVMProcess">IMachine::launchVMProcess</link>
1968 which returns an IProgress object. Note again that the method name is
1969 capitalized:
1970 <screen>IProgress *progress;
1971...
1972rc = IMachine_LaunchVMProcess(
1973 machine, /* this */
1974 session, /* arg 1 */
1975 sessionType, /* arg 2 */
1976 env, /* arg 3 */
1977 &amp;progress /* Out */
1978);</screen></para>
1979
1980 <para>All objects with their methods and attributes are documented
1981 in <xref linkend="sdkref_classes"/>.</para>
1982 </sect3>
1983
1984 <sect3 id="c-string-handling">
1985 <title>String handling</title>
1986
1987 <para>When dealing with strings you have to be aware of a string's
1988 encoding and ownership.</para>
1989
1990 <para>Internally, the API uses UTF-16 encoded strings. A set of
1991 conversion functions is provided to convert other encodings to and
1992 from UTF-16. The type of a UTF-16 character is
1993 <computeroutput>BSTR</computeroutput> (or its constant counterpart
1994 <computeroutput>CBSTR</computeroutput>), which is an array type,
1995 represented by a pointer to the start of the zero-terminated string.
1996 There are functions for converting between UTF-8 and UTF-16 strings
1997 available through <code>g_pVBoxFuncs</code>:
1998 <screen>int (*pfnUtf16ToUtf8)(CBSTR pwszString, char **ppszString);
1999int (*pfnUtf8ToUtf16)(const char *pszString, BSTR *ppwszString);</screen></para>
2000
2001 <para>The ownership of a string determines who is responsible for
2002 releasing resources associated with the string. Whenever the API
2003 creates a string (essentially for output parameters), ownership is
2004 transferred to the caller. To avoid resource leaks, the caller
2005 should release resources once the string is no longer needed.
2006 There are plenty of examples in the sample code.</para>
2007 </sect3>
2008
2009 <sect3 id="c-safearray">
2010 <title>Array handling</title>
2011
2012 <para>Arrays are handled somewhat similarly to strings, with the
2013 additional information of the number of elements in the array. The
2014 exact details of string passing depends on the platform middleware
2015 (COM/XPCOM), and therefore the C binding offers helper functions to
2016 gloss over these differences.</para>
2017
2018 <para>Passing arrays as input parameters to API methods is usually
2019 done by the following sequence, calling a hypothetical
2020 <code>IArrayDemo_PassArray</code> API method:
2021 <screen>static const ULONG aElements[] = { 1, 2, 3, 4 };
2022ULONG cElements = sizeof(aElements) / sizeof(aElements[0]);
2023SAFEARRAY *psa = NULL;
2024psa = g_pVBoxFuncs->pfnSafeArrayCreateVector(VT_I4, 0, cElements);
2025g_pVBoxFuncs->pfnSafeArrayCopyInParamHelper(psa, aElements, sizeof(aElements));
2026IArrayDemo_PassArray(pThis, ComSafeArrayAsInParam(psa));
2027g_pVBoxFuncs->pfnSafeArrayDestroy(psa);</screen></para>
2028
2029 <para>Likewise, getting arrays results from output parameters is done
2030 using helper functions which manage memory allocations as part of
2031 their other functionality:
2032 <screen>SAFEARRAY *psa = g_pVBoxFuncs->pfnSafeArrayOutParamAlloc();
2033ULONG *pData;
2034ULONG cElements;
2035IArrayDemo_ReturnArray(pThis, ComSafeArrayAsOutTypeParam(psa, ULONG));
2036g_pVBoxFuncs->pfnSafeArrayCopyOutParamHelper((void **)&amp;pData, &amp;cElements, VT_I4, psa);
2037g_pVBoxFuncs->pfnSafeArrayDestroy(psa);</screen></para>
2038
2039 <para>This covers the necessary functionality for all array element
2040 types except interface references. These need special helpers to
2041 manage the reference counting correctly. The following code snippet
2042 gets the list of VMs, and passes the first IMachine reference to
2043 another API function (assuming that there is at least one element
2044 in the array, to simplify the example):
2045 <screen>SAFEARRAY psa = g_pVBoxFuncs->pfnSafeArrayOutParamAlloc();
2046IMachine **machines = NULL;
2047ULONG machineCnt = 0;
2048ULONG i;
2049IVirtualBox_get_Machines(virtualBox, ComSafeArrayAsOutIfaceParam(machinesSA, IMachine *));
2050g_pVBoxFuncs->pfnSafeArrayCopyOutIfaceParamHelper((IUnknown ***)&amp;machines, &amp;machineCnt, machinesSA);
2051g_pVBoxFuncs->pfnSafeArrayDestroy(machinesSA);
2052/* Now "machines" contains the IMachine references, and machineCnt the
2053 * number of elements in the array. */
2054...
2055SAFEARRAY *psa = g_pVBoxFuncs->pfnSafeArrayCreateVector(VT_IUNKNOWN, 0, 1);
2056g_pVBoxFuncs->pfnSafeArrayCopyInParamHelper(psa, (void *)&amp;machines[0], sizeof(machines[0]));
2057IVirtualBox_GetMachineStates(ComSafeArrayAsInParam(psa), ...);
2058...
2059g_pVBoxFuncs->pfnSafeArrayDestroy(psa);
2060for (i = 0; i &lt; machineCnt; ++i)
2061{
2062 IMachine *machine = machines[i];
2063 IMachine_Release(machine);
2064}
2065free(machines);</screen></para>
2066
2067 <para>Handling output parameters needs more special handling than
2068 input parameters, thus only for the former are there special helpers
2069 while the latter is handled through the generic array support.</para>
2070 </sect3>
2071
2072 <sect3 id="c-eventhandling">
2073 <title>Event handling</title>
2074
2075 <para>The VirtualBox API offers two types of event handling, active
2076 and passive, and consequently there is support for both with the
2077 C API binding. Active event handling (based on asynchronous
2078 callback invocation for event delivery) is more difficult, as it
2079 requires the construction of valid C++ objects in C, which is
2080 inherently platform and compiler dependent. Passive event handling
2081 is much simpler, it relies on an event loop, fetching events and
2082 triggering the necessary handlers explicitly in the API client code.
2083 Both approaches depend on an event loop to make sure that events
2084 get delivered in a timely manner but otherwise differ in what
2085 else is required to implement the respective event handler type.</para>
2086
2087 <para>The C API sample contains code for both event handling styles,
2088 and one has to modify the appropriate <code>#define</code> to select
2089 which style is actually used by the compiled program. It allows a
2090 good comparison between the two variants and the code sequences are
2091 probably worth reusing without much change in other API clients
2092 with only minor adaptions.</para>
2093
2094 <para>Active event handling needs to ensure that the following helper
2095 function is called frequently enough in the primary thread:
2096 <screen>g_pVBoxFuncs->pfnProcessEventQueue(cTimeoutMS);</screen></para>
2097
2098 <para>The actual event handler implementation is quite tedious, as
2099 it has to implement a complete API interface. Especially on Windows
2100 it is a lot of work to implement the complicated
2101 <code>IDispatch</code> interface, requiring loading COM type
2102 information and using it in the <code>IDispatch</code> method
2103 implementation. Overall this is quite tedious compared to passive
2104 event handling.</para>
2105
2106 <para>Passive event handling uses a similar event loop structure,
2107 which requires calling the following function in a loop, and
2108 processing the returned event appropriately:
2109 <screen>rc = IEventSource_GetEvent(pEventSource, pListener, cTimeoutMS, &amp;pEvent);</screen></para>
2110
2111 <para>After processing the event it needs to be marked as processed
2112 with the following method call:
2113 <screen>rc = IEventSource_EventProcessed(pEventSource, pListener, pEvent);</screen></para>
2114
2115 <para>This is vital for vetoable events, as they would be stuck
2116 otherwise, waiting on whether the veto comes or not. It does not do any
2117 harm for other event types, and in the end is cheaper than checking
2118 if the event at hand is vetoable or not.</para>
2119
2120 <para>The general event handling concepts are described in the API
2121 specification (see <xref linkend="events"/>), including how to
2122 aggregate multiple event sources for processing in one event loop.
2123 As mentioned, the sample illustrates the practical aspects of how to
2124 use both types of event handling, active and passive, from a C
2125 application. Additional hints are in the comments documenting
2126 the helper methods in
2127 <computeroutput>VBoxCAPI_v&VBOX_VERSION_MAJOR;_&VBOX_VERSION_MINOR;.h</computeroutput>.
2128 The code complexity of active event handling (and its inherently
2129 platform/compiler specific aspects) should be motivation to use passive
2130 event handling wherever possible.</para>
2131 </sect3>
2132
2133 <sect3 id="c-uninitialization">
2134 <title>C API uninitialization</title>
2135
2136 <para>Uninitialization is performed by
2137 <computeroutput>g_pVBoxFuncs-&gt;pfnClientUninitialize().</computeroutput>
2138 If your program can exit in more than one place, it is a good idea
2139 to install this function as an exit handler using the C library function
2140 <computeroutput>atexit()</computeroutput> just after calling
2141 <computeroutput>g_pVBoxFuncs-&gt;pfnClientInitialize()</computeroutput>
2142 , e.g. <screen>#include &lt;stdlib.h&gt;
2143#include &lt;stdio.h&gt;
2144
2145...
2146
2147/*
2148 * Make sure g_pVBoxFuncs-&gt;pfnClientUninitialize() is called at exit, no
2149 * matter if we return from the initial call to main or call exit()
2150 * somewhere else. Note that atexit registered functions are not
2151 * called upon abnormal termination, i.e. when calling abort() or
2152 * signal().
2153 */
2154
2155if (atexit(g_pVBoxFuncs-&gt;pfnClientUninitialize()) != 0) {
2156 fprintf(stderr, "failed to register g_pVBoxFuncs-&gt;pfnClientUninitialize()\n");
2157 exit(EXIT_FAILURE);
2158}</screen></para>
2159
2160 <para>Another idea would be to write your own <computeroutput>void
2161 myexit(int status)</computeroutput> function, calling
2162 <computeroutput>g_pVBoxFuncs-&gt;pfnClientUninitialize()</computeroutput>
2163 followed by the real <computeroutput>exit()</computeroutput>, and
2164 use it instead of <computeroutput>exit()</computeroutput> throughout
2165 your program and at the end of
2166 <computeroutput>main.</computeroutput></para>
2167
2168 <para>If you expect your program to be terminated by a signal (e.g. a
2169 user types CTRL-C sending SIGINT) you might want to install a signal
2170 handler setting a flag noting that a signal was sent and then
2171 calling
2172 <computeroutput>g_pVBoxFuncs-&gt;pfnClientUninitialize()</computeroutput>
2173 later on, <emphasis>not</emphasis> from the handler itself.</para>
2174
2175 <para>That said, if a client program forgets to call
2176 <computeroutput>g_pVBoxFuncs-&gt;pfnClientUninitialize()</computeroutput>
2177 before it terminates, there is a mechanism in place which will
2178 eventually release references held by the client. On Windows it can
2179 take quite a while, on the order of 6-7 minutes.</para>
2180 </sect3>
2181
2182 <sect3 id="c-linking">
2183 <title>Compiling and linking</title>
2184
2185 <para>A program using the C binding has to open the library during
2186 runtime using the help of the glue code provided and as shown in the
2187 example <computeroutput>tstCAPIGlue.c</computeroutput>.
2188 Compilation and linking can be achieved with a makefile fragment
2189 similar to:<screen># Where is the SDK directory?
2190PATH_SDK = ../../..
2191CAPI_INC = -I$(PATH_SDK)/bindings/c/include
2192ifdef ProgramFiles
2193PLATFORM_INC = -I$(PATH_SDK)/bindings/mscom/include
2194PLATFORM_LIB = $(PATH_SDK)/bindings/mscom/lib
2195else
2196PLATFORM_INC = -I$(PATH_SDK)/bindings/xpcom/include
2197PLATFORM_LIB = $(PATH_SDK)/bindings/xpcom/lib
2198endif
2199GLUE_DIR = $(PATH_SDK)/bindings/c/glue
2200GLUE_INC = -I$(GLUE_DIR)
2201
2202# Compile Glue Library
2203VBoxCAPIGlue.o: $(GLUE_DIR)/VBoxCAPIGlue.c
2204 $(CC) $(CFLAGS) $(CAPI_INC) $(PLATFORM_INC) $(GLUE_INC) -o $@ -c $&lt;
2205
2206# Compile interface ID list
2207VirtualBox_i.o: $(PLATFORM_LIB)/VirtualBox_i.c
2208 $(CC) $(CFLAGS) $(CAPI_INC) $(PLATFORM_INC) $(GLUE_INC) -o $@ -c $&lt;
2209
2210# Compile program code
2211program.o: program.c
2212 $(CC) $(CFLAGS) $(CAPI_INC) $(PLATFORM_INC) $(GLUE_INC) -o $@ -c $&lt;
2213
2214# Link program.
2215program: program.o VBoxCAPICGlue.o VirtualBox_i.o
2216 $(CC) -o $@ $^ -ldl -lpthread</screen></para>
2217 </sect3>
2218
2219 <sect3 id="capi_conversion">
2220 <title>Conversion of code using legacy C bindings</title>
2221
2222 <para>This section aims to make the task of converting code using the
2223 legacy C bindings to the new style a breeze by following these key
2224 steps.</para>
2225
2226 <para>One necessary change is adjusting your Makefile to reflect the
2227 different include paths. As shown in the makefile fragment above, there
2228 are now three relevant include directories. The XPCOM include directory
2229 is still relevant for platforms where the XPCOM middleware is used but
2230 most of its include files live elsewhere now so it's good to have it
2231 last. Additionally the <computeroutput>VirtualBox_i.c</computeroutput>
2232 file needs to be compiled and linked to the program since it contains
2233 the interface IDs (IIDs) relevant for the VirtualBox API, making sure
2234 they are not replicated endlessly if the code refers to them
2235 frequently.</para>
2236
2237 <para>The C API client code should include
2238 <computeroutput>VBoxCAPIGlue.h</computeroutput> instead of
2239 <computeroutput>VBoxXPCOMCGlue.h</computeroutput> or
2240 <computeroutput>VBoxCAPI_v&VBOX_VERSION_MAJOR;_&VBOX_VERSION_MINOR;.h</computeroutput>,
2241 as this makes sure the correct macros and internal translations are
2242 selected.</para>
2243
2244 <para>All API method calls (anything mentioning <code>vtbl</code>)
2245 should be rewritten using the convenience macros for calling methods,
2246 as these hide the internal details, are generally easier to
2247 use, and are shorter to type. You should remove as many as possible
2248 <code>(nsISupports **)</code> or similar typecasts, as the new style
2249 should use the correct type in most places, increasing the type
2250 safety in case of an error in the source code.</para>
2251
2252 <para>To gloss over the platform differences, API client code should
2253 no longer rely on XPCOM specific interface names such as
2254 <code>nsISupports</code>, <code>nsIException</code> and
2255 <code>nsIEventQueue</code>, and replace them by the platform
2256 independent interface names <code>IUnknown</code> and
2257 <code>IErrorInfo</code> for the first two respectively. Event queue
2258 handling should be replaced by using the platform independent way
2259 described in <xref linkend="c-eventhandling"/>.</para>
2260
2261 <para>Finally adjust the string and array handling to use the new
2262 helpers, as these make sure the code works without changes with
2263 both COM and XPCOM, which are significantly different in this area.
2264 The code should be double checked to see that it uses the correct way to
2265 manage memory and is freeing it only after the last use.</para>
2266 </sect3>
2267
2268 <sect3 id="xpcom_cbinding">
2269 <title>Legacy C bindings to VirtualBox API for XPCOM</title>
2270
2271 <note>
2272 <para>This section applies to Linux, Mac OS X and Solaris
2273 hosts only and describes deprecated use of the API from C.</para>
2274 </note>
2275
2276 <para>Starting with version 2.2, VirtualBox offers C bindings for
2277 its API which works only on platforms using XPCOM. Refer to the
2278 old SDK documentation (included in the SDK packages for version 4.3.6
2279 or earlier) since it still applies unchanged. The fundamental concepts
2280 are similar (but the syntactical details are quite different) to the
2281 newer cross-platform C bindings which should be used for all new code,
2282 as the support for the old C bindings will go away in a major release
2283 after version 4.3.</para>
2284 </sect3>
2285 </sect2>
2286 </sect1>
2287 </chapter>
2288
2289 <chapter id="concepts">
2290 <title>Basic VirtualBox concepts; some examples</title>
2291
2292 <para>The following explains some basic VirtualBox concepts such as the
2293 VirtualBox object, sessions and how virtual machines are manipulated and
2294 launched using the Main API. The coding examples use a pseudo-code style
2295 closely related to the object-oriented web service (OOWS) for JAX-WS.
2296 Depending on which environment you are using, you will need to adjust the
2297 examples.</para>
2298
2299 <sect1>
2300 <title>Obtaining basic machine information. Reading attributes</title>
2301
2302 <para>Any program using the Main API will first need access to the
2303 global VirtualBox object (see
2304 <link linkend="IVirtualBox">IVirtualBox</link>), from which all other
2305 functionality of the API is derived. With the OOWS for JAX-WS, this is
2306 returned from the
2307 <link linkend="IWebsessionManager__logon">IWebsessionManager::logon()</link>
2308 call.</para>
2309
2310 <para>To enumerate virtual machines, one would look at the "machines"
2311 array attribute in the VirtualBox object (see
2312 <link linkend="IVirtualBox__machines">IVirtualBox::machines</link>).
2313 This array contains all virtual machines currently registered with the
2314 host, each of them being an instance of
2315 <link linkend="IMachine">IMachine</link>.
2316 From each such instance, one can query additional information, such as
2317 the UUID, the name, memory, operating system and more by looking at the
2318 attributes; see the attributes list in
2319 <link linkend="IMachine">IMachine</link> documentation.</para>
2320
2321 <para>As mentioned in the preceding chapters, depending on your
2322 programming environment, attributes are mapped to corresponding "get"
2323 and (if the attribute is not read-only) "set" methods. So when the
2324 documentation says that IMachine has a
2325 "<link linkend="IMachine__name">name</link>" attribute, this means you
2326 need to code something
2327 like the following to get the machine's name:
2328 <screen>IMachine machine = ...;
2329String name = machine.getName();</screen>
2330 Boolean attribute getters can sometimes be called
2331 <computeroutput>isAttribute()</computeroutput> due to JAX-WS naming
2332 conventions.</para>
2333 </sect1>
2334
2335 <sect1>
2336 <title>Changing machine settings: Sessions</title>
2337
2338 <para>As described in the previous section, to read a machine's attribute,
2339 one invokes the corresponding "get" method. One would think that to
2340 change settings of a machine, it would suffice to call the corresponding
2341 "set" method -- for example, to set a VM's memory to 1024 MB, one would
2342 call <computeroutput>setMemorySize(1024)</computeroutput>. Try that, and
2343 you will get an error: "The machine is not mutable."</para>
2344
2345 <para>So unfortunately, things are not that easy. VirtualBox is a
2346 complicated environment in which multiple processes compete for possibly
2347 the same resources, especially machine settings. As a result, machines
2348 must be "locked" before they can either be modified or started. This is
2349 to prevent multiple processes from making conflicting changes to a
2350 machine: it should, for example, not be allowed to change the memory
2351 size of a virtual machine while it is running. (You can't add more
2352 memory to a real computer while it is running either, at least not to an
2353 ordinary PC.) Also, two processes must not change settings at the same
2354 time, or start a machine at the same time.</para>
2355
2356 <para>These requirements are implemented in the Main API by way of
2357 "sessions", in particular, the <link linkend="ISession">ISession</link>
2358 interface. Each process which talks to
2359 VirtualBox needs its own instance of ISession. In the web service, you
2360 can request the creation of such an object by calling
2361 <link linkend="IWebsessionManager__getSessionObject">IWebsessionManager::getSessionObject()</link>.
2362 More complex management tasks might need multiple instances of ISession,
2363 and each call returns a new one.</para>
2364
2365 <para>This session object must then be used like a mutex semaphore in
2366 common programming environments. Before you can change machine settings,
2367 you must write-lock the machine by calling
2368 <link linkend="IMachine__lockMachine">IMachine::lockMachine()</link>
2369 with your process's session object.</para>
2370
2371 <para>After the machine has been locked, the
2372 <link linkend="ISession__machine">ISession::machine</link> attribute
2373 contains a copy of the original IMachine object upon which the session
2374 was opened, but this copy is "mutable": you can invoke "set" methods on
2375 it.</para>
2376
2377 <para>When done making the changes to the machine, you must call
2378 <link linkend="IMachine__saveSettings">IMachine::saveSettings()</link>,
2379 which will copy the changes you have made from your "mutable" machine
2380 back to the real machine and write them out to the machine settings XML
2381 file. This will make your changes permanent.</para>
2382
2383 <para>Finally, it is important to always unlock the machine again, by
2384 calling
2385 <link linkend="ISession__unlockMachine">ISession::unlockMachine()</link>.
2386 Otherwise, when the calling process exits, the machine will be moved to the
2387 "aborted" state, which can lead to loss of data.</para>
2388
2389 <para>So, as an example, the sequence to change a machine's memory to
2390 1024 MB is something like this:<screen>IWebsessionManager mgr ...;
2391IVirtualBox vbox = mgr.logon(user, pass);
2392...
2393IMachine machine = ...; // read-only machine
2394ISession session = mgr.getSessionObject();
2395machine.lockMachine(session, LockType.Write); // machine is now locked for writing
2396IMachine mutable = session.getMachine(); // obtain the mutable machine copy
2397mutable.setMemorySize(1024);
2398mutable.saveSettings(); // write settings to XML
2399session.unlockMachine();</screen></para>
2400 </sect1>
2401
2402 <sect1>
2403 <title>Launching virtual machines</title>
2404
2405 <para>To launch a virtual machine, you call
2406 <link linkend="IMachine__launchVMProcess">IMachine::launchVMProcess()</link>.
2407 This instructs the VirtualBox engine to start a new process containing the
2408 virtual machine. The host system sees each virtual machine as a single
2409 process, even if the virtual machine has hundreds of its own processes
2410 running inside it. (This new VM process in turn obtains a write lock on
2411 the machine, as described above, to prevent conflicting changes from
2412 other processes; this is why opening another session will fail while the
2413 VM is running.)</para>
2414
2415 <para>Starting a machine looks something like this:
2416 <screen>IWebsessionManager mgr ...;
2417IVirtualBox vbox = mgr.logon(user, pass);
2418...
2419IMachine machine = ...; // read-only machine
2420ISession session = mgr.getSessionObject();
2421IProgress prog = machine.launchVMProcess(session,
2422 "gui", // session type
2423 ""); // possibly environment setting
2424prog.waitForCompletion(10000); // give the process 10 secs
2425if (prog.getResultCode() != 0) // check success
2426 System.out.println("Cannot launch VM!")</screen></para>
2427
2428 <para>The caller's session object can then be used as a sort of remote
2429 control to the VM process that was launched. It contains a "console"
2430 object (see <link linkend="ISession__console">ISession::console</link>)
2431 with which the VM can be paused,
2432 stopped, snapshotted or other things.</para>
2433 </sect1>
2434
2435 <sect1 id="events">
2436 <title>VirtualBox events</title>
2437
2438 <para>In VirtualBox, "events" provide a uniform mechanism to register
2439 for and consume specific events. A VirtualBox client can register an
2440 "event listener" (represented by the
2441 <link linkend="IEventListener">IEventListener</link> interface), which
2442 will then get notified by the server when an event (represented by the
2443 <link linkend="IEvent">IEvent</link> interface) happens.</para>
2444
2445 <para>The IEvent interface is an abstract parent interface for all
2446 events that can occur in VirtualBox. The actual events that the server
2447 sends out belong to one of the specific subclasses, for example
2448 <link linkend="IMachineStateChangedEvent">IMachineStateChangedEvent</link>
2449 or
2450 <link linkend="IMediumChangedEvent">IMediumChangedEvent</link>.</para>
2451
2452 <para>As an example, the VirtualBox GUI waits for machine events so it can
2453 update its display when the machine state changes or machine settings are
2454 modified, even if this happens in another client. This is how the GUI can
2455 automatically refresh its display even if you manipulate a machine from
2456 a different client such as VBoxManage.</para>
2457
2458 <para>To register an event listener to listen for events, you would use code
2459 similar to the following:<screen>EventSource es = console.getEventSource();
2460IEventListener listener = es.createListener();
2461VBoxEventType aTypes[] = (VBoxEventType.OnMachineStateChanged);
2462 // list of event types to listen for
2463es.registerListener(listener, aTypes, false /* active */);
2464 // register passive listener
2465IEvent ev = es.getEvent(listener, 1000);
2466 // wait up to one second for event to happen
2467if (ev != null)
2468{
2469 // downcast to specific event interface (in this case we have only registered
2470 // for one type, otherwise IEvent::type would tell us)
2471 IMachineStateChangedEvent mcse = IMachineStateChangedEvent.queryInterface(ev);
2472 ... // inspect and do something
2473 es.eventProcessed(listener, ev);
2474}
2475...
2476es.unregisterListener(listener); </screen></para>
2477
2478 <para>A graphical user interface application would most likely want to start
2479 its own thread to wait for events and then process these in a loop.</para>
2480
2481 <para>The events mechanism was introduced with VirtualBox 3.3 and
2482 replaces various callback interfaces which were called for each event in
2483 the interface. The callback mechanism was not compatible with scripting
2484 languages, local Java bindings, and remote web services as they do not
2485 support callbacks. The new mechanism with events and event listeners
2486 works with all of these.</para>
2487
2488 <para>To simplify development of applications using events, the concept of
2489 an event aggregator was introduced. Essentially it's a mechanism to
2490 aggregate multiple event sources into one single event source, and then work
2491 with this single aggregated event source instead of the original sources. As
2492 an example, one can try out the VirtualBox Python shell's
2493 <computeroutput>recordDemo</computeroutput> option which records mouse and
2494 keyboard events using an event aggregator and displays them as separate event
2495 sources. The VirtualBox Python shell (vboxshell.py) is shipped with the SDK.
2496 The <computeroutput>recordDemo</computeroutput> code is essentially:<screen>
2497 listener = console.eventSource.createListener()
2498 agg = console.eventSource.createAggregator([console.keyboard.eventSource, console.mouse.eventSource])
2499 agg.registerListener(listener, [ctx['global'].constants.VBoxEventType_Any], False)
2500 registered = True
2501 end = time.time() + dur
2502 while time.time() &lt; end:
2503 ev = agg.getEvent(listener, 1000)
2504 processEent(ev)
2505 agg.unregisterListener(listener)</screen> Without using aggregators
2506 consumers would have to either poll on both sources or start multiple
2507 threads to block on those sources.</para>
2508 </sect1>
2509 </chapter>
2510
2511 <chapter id="vboxshell">
2512 <title>The VirtualBox shell</title>
2513
2514 <para>VirtualBox comes with an extensible shell which allows you to
2515 control your virtual machines from the command line. It is also a
2516 non-trivial example of how to use the VirtualBox APIs from Python for all
2517 three styles of the API (COM/XPCOM/WS).</para>
2518
2519 <para>You can easily extend this shell with your own commands. Simply create
2520 a subdirectory named
2521 <computeroutput>.config/VirtualBox/shexts</computeroutput> in your home
2522 directory (<computeroutput>.VirtualBox/shexts</computeroutput>
2523 on Windows systems and
2524 <computeroutput>Library/VirtualBox/shexts</computeroutput> on macOS systems)
2525 and put a Python file implementing your shell extension commands in this
2526 directory. This file must have an array named
2527 <computeroutput>commands</computeroutput> which contains your command
2528 definitions: <screen>
2529 commands = {
2530 'cmd1': ['Command cmd1 help', cmd1],
2531 'cmd2': ['Command cmd2 help', cmd2]
2532 }
2533 </screen> For example, to create a command for creating hard drive
2534 images, the following code can be used: <screen>
2535 def createHdd(ctx,args):
2536 # Show some meaningful error message on wrong input
2537 if (len(args) &lt; 3):
2538 print "usage: createHdd sizeM location type"
2539 return 0
2540
2541 # Get arguments
2542 size = int(args[1])
2543 loc = args[2]
2544 if len(args) &gt; 3:
2545 format = args[3]
2546 else:
2547 # And provide some meaningful defaults
2548 format = "vdi"
2549
2550 # Call VirtualBox API, using context's fields
2551 hdd = ctx['vb'].createMedium(format, loc, ctx['global'].constants.AccessMode_ReadWrite, \
2552 ctx['global'].constants.DeviceType_HardDisk)
2553 # Access constants using ctx['global'].constants
2554 progress = hdd.createBaseStorage(size, (ctx['global'].constants.MediumVariant_Standard, ))
2555 # use standard progress bar mechanism
2556 ctx['progressBar'](progress)
2557
2558
2559 # Report errors
2560 if not hdd.id:
2561 print "cannot create disk (file %s exist?)" %(loc)
2562 return 0
2563
2564 # Give user some feedback on success too
2565 print "created HDD with id: %s" %(hdd.id)
2566
2567 # 0 means continue execution, other values mean exit from the interpreter
2568 return 0
2569
2570 commands = {
2571 'myCreateHDD': ['Create virtual HDD, createHdd size location type', createHdd]
2572 }
2573 </screen> Just store the above text in a file named
2574 <computeroutput>createHdd</computeroutput> (or any other meaningful name)
2575 in the <computeroutput>shexts</computeroutput> directory located as
2576 described above and then start the VirtualBox shell or just issue the
2577 <computeroutput>reloadExts</computeroutput> command if the shell is
2578 already running. Your new command will now be available.</para>
2579 </chapter>
2580
2581 <chapter id="vboxarm">
2582 <title>Main API changes to support the ARM64 architecture</title>
2583
2584 <para>VirtualBox 7.1 introduces support for running virtual machines on
2585 hosts containing an ARM CPU. Since VirtualBox has been designed and
2586 developed for virtualizing x86 hardware since its inception adding
2587 support for ARM CPUs required a variety of changes to the Main API to
2588 accommodate two different CPU architectures.</para>
2589
2590 <sect1>
2591 <title>Overview of the Changes to the Main API</title>
2592
2593 <para>In order to support two different types of processor architecture
2594 in the VirtualBox Main API the key abstraction was the addition of a new
2595 interface named <link linkend="IPlatform">IPlatform</link> which contains
2596 the details which relate to the operating environment of a VM. The
2597 <link linkend="IPlatform">IPlatform</link> interface is distinct from the
2598 VM itself (the <link linkend="IMachine">IMachine</link> interface), the VM
2599 management interfaces (<link linkend="IVirtualBox">IVirtualBox</link> and
2600 <link linkend="IConsole">IConsole</link>), as well as the global properties of
2601 the VM (the <link linkend="ISystemProperties">ISystemProperties</link> interface).
2602 The contents of the <link linkend="IPlatform">IPlatform</link> interface can be
2603 broken down into three different categories:</para>
2604 <itemizedlist>
2605 <listitem>
2606 <para>properties relating to the VM which are CPU architecture-neutral (<link linkend="IPlatformProperties">IPlatformProperties</link>)</para>
2607 </listitem>
2608 <listitem>
2609 <para>properties which are CPU architecture-specific (<link linkend="IPlatformX86">IPlatformX86</link> or <link linkend="IPlatformARM">IPlatformARM</link>)</para>
2610 </listitem>
2611 <listitem>
2612 <para>attributes of the VM which are CPU architecture-neutral such as:</para>
2613 <itemizedlist>
2614 <listitem><para>the architecture of the VM (<link linkend="IPlatform__architecture">IPlatform::architecture</link>)</para>
2615 </listitem>
2616 <listitem><para>the type of chipset used by the VM (<link linkend="IPlatform__chipsetType">IPlatform::chipsetType</link>)</para>
2617 </listitem>
2618 <listitem><para>the type of IOMMU used by the VM (<link linkend="IPlatform__iommuType">IPlatform::iommuType</link>).</para>
2619 </listitem>
2620 </itemizedlist>
2621 </listitem>
2622 </itemizedlist>
2623
2624 <para>The <link linkend="IPlatform">IPlatform</link> interface can be retrieved from
2625 the <link linkend="IMachine">IMachine</link> interface via the new
2626 <link linkend="IMachine__platform">IMachine::platform</link> attribute. The
2627 <link linkend="IPlatform__architecture">IPlatform::architecture</link> attribute
2628 returns the <emphasis>architecture</emphasis> type in a new enumeration named
2629 <link linkend="PlatformArchitecture">PlatformArchitecture</link>. This enumeration value
2630 can be used to determine which CPU-specific properties to query, for example:
2631 <screen>
2632 IPlatform platform;
2633 result = machine.getPlatform(platform);
2634
2635 PlatformArchitecture_T platformArch;
2636 result = platform.getArchitecture(platformArch);
2637 if (platformArch == x86)
2638 IPlatformX86 platformX86;
2639 result = platform.getX86(platformX86);
2640 else if (platformArch == ARM)
2641 IPlatformARM platformARM;
2642 result = platform.getARM(platformARM);
2643 else
2644 error;
2645 </screen>
2646
2647 The value of the <link linkend="PlatformArchitecture">PlatformArchitecture</link> enumeration
2648 can also be used when creating a new VM using <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine</link>.
2649 </para>
2650
2651 <para>The CPU architecture-neutral properties in (<link linkend="IPlatformProperties">IPlatformProperties</link>)
2652 can be found in several places:</para>
2653 <itemizedlist>
2654 <listitem>
2655 <para>They can be retrieved from the <link linkend="IPlatform__properties">IPlatform::properties</link>
2656 attribute.</para>
2657 </listitem>
2658 <listitem>
2659 <para>They can be retrieved from the <link linkend="ISystemProperties__platform">ISystemProperties::platform</link>
2660 attribute.</para>
2661 </listitem>
2662 <listitem>
2663 <para>They can retrieved from the <link linkend="IVirtualBox">IVirtualBox</link> interface
2664 using the new <link linkend="IVirtualBox__getPlatformProperties">IVirtualBox::getPlatformProperties</link> method.
2665 </para>
2666 </listitem>
2667 </itemizedlist>
2668
2669 <para>The attributes and methods contained in <link linkend="IPlatformProperties">IPlatformProperties</link>
2670 were moved from the <link linkend="ISystemProperties">ISystemProperties</link> interface as they
2671 can vary based on the platform of the VM:</para>
2672
2673 <table>
2674 <title>IPlatformProperties Attributes</title>
2675 <tgroup cols="2" style="verywide">
2676 <tbody>
2677 <row>
2678 <entry><emphasis role="bold">Original Attribute</emphasis></entry>
2679 <entry><emphasis role="bold">New Attribute</emphasis></entry>
2680 </row>
2681
2682 <row>
2683 <entry>ISystemProperties::rawModeSupported</entry>
2684 <entry><link linkend="IPlatformProperties__rawModeSupported">IPlatformProperties::rawModeSupported</link></entry>
2685 </row>
2686
2687 <row>
2688 <entry>ISystemProperties::exclusiveHwVirt</entry>
2689 <entry><link linkend="IPlatformProperties__exclusiveHwVirt">IPlatformProperties::exclusiveHwVirt</link></entry>
2690 </row>
2691
2692 <row>
2693 <entry>ISystemProperties::serialPortCount</entry>
2694 <entry><link linkend="IPlatformProperties__serialPortCount">IPlatformProperties::serialPortCount</link></entry>
2695 </row>
2696
2697 <row>
2698 <entry>ISystemProperties::parallelPortCount</entry>
2699 <entry><link linkend="IPlatformProperties__parallelPortCount">IPlatformProperties::parallelPortCount</link></entry>
2700 </row>
2701
2702 <row>
2703 <entry>ISystemProperties::maxBootPosition</entry>
2704 <entry><link linkend="IPlatformProperties__maxBootPosition">IPlatformProperties::maxBootPosition</link></entry>
2705 </row>
2706
2707 <row>
2708 <entry>ISystemProperties::supportedParavirtProviders[]</entry>
2709 <entry><link linkend="IPlatformProperties__supportedParavirtProviders">IPlatformProperties::supportedParavirtProviders[]</link></entry>
2710 </row>
2711
2712 <row>
2713 <entry>ISystemProperties::supportedFirmwareTypes[]</entry>
2714 <entry><link linkend="IPlatformProperties__supportedFirmwareTypes">IPlatformProperties::supportedFirmwareTypes[]</link></entry>
2715 </row>
2716
2717 <row>
2718 <entry>ISystemProperties::supportedGuestOSTypes[]</entry>
2719 <entry><link linkend="IPlatformProperties__supportedGuestOSTypes">IPlatformProperties::supportedGuestOSTypes[]</link></entry>
2720 </row>
2721
2722 <row>
2723 <entry>ISystemProperties::supportedGraphicsControllerTypes[]</entry>
2724 <entry><link linkend="IPlatformProperties__supportedGraphicsControllerTypes">IPlatformProperties::supportedGraphicsControllerTypes[]</link></entry>
2725 </row>
2726
2727 <row>
2728 <entry>ISystemProperties::supportedNetAdpPromiscModePols[]</entry>
2729 <entry><link linkend="IPlatformProperties__supportedNetAdpPromiscModePols">IPlatformProperties::supportedNetAdpPromiscModePols[]</link></entry>
2730 </row>
2731
2732 <row>
2733 <entry>ISystemProperties::supportedNetworkAdapterTypes[]</entry>
2734 <entry><link linkend="IPlatformProperties__supportedNetworkAdapterTypes">IPlatformProperties::supportedNetworkAdapterTypes[]</link></entry>
2735 </row>
2736
2737 <row>
2738 <entry>ISystemProperties::supportedUartTypes[]</entry>
2739 <entry><link linkend="IPlatformProperties__supportedUartTypes">IPlatformProperties::supportedUartTypes[]</link></entry>
2740 </row>
2741
2742 <row>
2743 <entry>ISystemProperties::supportedUSBControllerTypes[]</entry>
2744 <entry><link linkend="IPlatformProperties__supportedUSBControllerTypes">IPlatformProperties::supportedUSBControllerTypes[]</link></entry>
2745 </row>
2746
2747 <row>
2748 <entry>ISystemProperties::supportedAudioControllerTypes[]</entry>
2749 <entry><link linkend="IPlatformProperties__supportedAudioControllerTypes">IPlatformProperties::supportedAudioControllerTypes[]</link></entry>
2750 </row>
2751
2752 <row>
2753 <entry>ISystemProperties::supportedBootDevices[]</entry>
2754 <entry><link linkend="IPlatformProperties__supportedBootDevices">IPlatformProperties::supportedBootDevices[]</link></entry>
2755 </row>
2756
2757 <row>
2758 <entry>ISystemProperties::supportedStorageBuses[]</entry>
2759 <entry><link linkend="IPlatformProperties__supportedStorageBuses">IPlatformProperties::supportedStorageBuses[]</link></entry>
2760 </row>
2761
2762 <row>
2763 <entry>ISystemProperties::supportedStorageControllerTypes[]</entry>
2764 <entry><link linkend="IPlatformProperties__supportedStorageControllerTypes">IPlatformProperties::supportedStorageControllerTypes[]</link></entry>
2765 </row>
2766
2767 <row>
2768 <entry>ISystemProperties::supportedChipsetTypes[]</entry>
2769 <entry><link linkend="IPlatformProperties__supportedChipsetTypes">IPlatformProperties::supportedChipsetTypes[]</link></entry>
2770 </row>
2771
2772 <row>
2773 <entry>ISystemProperties::supportedIommuTypes[]</entry>
2774 <entry><link linkend="IPlatformProperties__supportedIommuTypes">IPlatformProperties::supportedIommuTypes[]</link></entry>
2775 </row>
2776
2777 <row>
2778 <entry>ISystemProperties::supportedTpmTypes[]</entry>
2779 <entry><link linkend="IPlatformProperties__supportedTpmTypes">IPlatformProperties::supportedTpmTypes[]</link></entry>
2780 </row>
2781
2782 </tbody>
2783 </tgroup>
2784 </table>
2785
2786 <table>
2787 <title>IPlatformProperties Attributes</title>
2788 <tgroup cols="2" style="verywide">
2789 <tbody>
2790 <row>
2791 <entry><emphasis role="bold">Original Method</emphasis></entry>
2792 <entry><emphasis role="bold">New Method</emphasis></entry>
2793 </row>
2794
2795 <row>
2796 <entry>ISystemProperties::getDeviceTypesForStorageBus</entry>
2797 <entry><link linkend="IPlatformProperties__getDeviceTypesForStorageBus">IPlatformProperties::getDeviceTypesForStorageBus</link></entry>
2798 </row>
2799
2800 <row>
2801 <entry>ISystemProperties::getMaxDevicesPerPortForStorageBus</entry>
2802 <entry><link linkend="IPlatformProperties__getMaxDevicesPerPortForStorageBus">IPlatformProperties::getMaxDevicesPerPortForStorageBus</link></entry>
2803 </row>
2804
2805 <row>
2806 <entry>ISystemProperties::getMaxInstancesOfStorageBus</entry>
2807 <entry><link linkend="IPlatformProperties__getMaxInstancesOfStorageBus">IPlatformProperties::getMaxInstancesOfStorageBus</link></entry>
2808 </row>
2809
2810 <row>
2811 <entry>ISystemProperties::getMaxInstancesOfUSBControllerType</entry>
2812 <entry><link linkend="IPlatformProperties__getMaxInstancesOfUSBControllerType">IPlatformProperties::getMaxInstancesOfUSBControllerType</link></entry>
2813 </row>
2814
2815 <row>
2816 <entry>ISystemProperties::getMaxNetworkAdapters</entry>
2817 <entry><link linkend="IPlatformProperties__getMaxNetworkAdapters">IPlatformProperties::getMaxNetworkAdapters</link></entry>
2818 </row>
2819
2820 <row>
2821 <entry>ISystemProperties::getMaxNetworkAdaptersOfType</entry>
2822 <entry><link linkend="IPlatformProperties__getMaxNetworkAdaptersOfType">IPlatformProperties::getMaxNetworkAdaptersOfType</link></entry>
2823 </row>
2824
2825 <row>
2826 <entry>ISystemProperties::getMaxPortCountForStorageBus</entry>
2827 <entry><link linkend="IPlatformProperties__getMaxPortCountForStorageBus">IPlatformProperties::getMaxPortCountForStorageBus</link></entry>
2828 </row>
2829
2830 <row>
2831 <entry>ISystemProperties::getMinPortCountForStorageBus</entry>
2832 <entry><link linkend="IPlatformProperties__getMinPortCountForStorageBus">IPlatformProperties::getMinPortCountForStorageBus</link></entry>
2833 </row>
2834
2835 <row>
2836 <entry>ISystemProperties::getStorageBusForControllerType</entry>
2837 <entry><link linkend="IPlatformProperties__getStorageBusForControllerType">IPlatformProperties::getStorageBusForControllerType</link></entry>
2838 </row>
2839
2840 <row>
2841 <entry>ISystemProperties::getStorageControllerHotplugCapable</entry>
2842 <entry><link linkend="IPlatformProperties__getStorageControllerHotplugCapable">IPlatformProperties::getStorageControllerHotplugCapable</link></entry>
2843 </row>
2844
2845 <row>
2846 <entry>ISystemProperties::getStorageControllerTypesForBus</entry>
2847 <entry><link linkend="IPlatformProperties__getStorageControllerTypesForBus">IPlatformProperties::getStorageControllerTypesForBus</link></entry>
2848 </row>
2849
2850 </tbody>
2851 </tgroup>
2852 </table>
2853
2854 <para>The single attribute and all of the properties contained in the new
2855 <link linkend="IPlatformX86">IPlatformX86</link> interface were moved from the
2856 <link linkend="IMachine">IMachine</link> interface as they are specific to the x86
2857 CPU architecture:</para>
2858
2859 <table>
2860 <title>IPlatformX86 Attribute</title>
2861 <tgroup cols="2">
2862 <tbody>
2863 <row>
2864 <entry><emphasis role="bold">Original Attribute</emphasis></entry>
2865 <entry><emphasis role="bold">New Attribute</emphasis></entry>
2866 </row>
2867
2868 <row>
2869 <entry>IMachine::HPETEnabled</entry>
2870 <entry><link linkend="IPlatformX86__HPETEnabled">IPlatformX86::HPETEnabled</link></entry>
2871 </row>
2872 </tbody>
2873 </tgroup>
2874 </table>
2875
2876 <table>
2877 <title>IPlatformX86 Methods</title>
2878 <tgroup cols="2">
2879 <tbody>
2880 <row>
2881 <entry><emphasis role="bold">Original Method</emphasis></entry>
2882 <entry><emphasis role="bold">New Method</emphasis></entry>
2883 </row>
2884
2885 <row>
2886 <entry>IMachine::getCPUIDLeaf</entry>
2887 <entry><link linkend="IPlatformX86__getCPUIDLeaf">IPlatformX86::getCPUIDLeaf</link></entry>
2888 </row>
2889
2890 <row>
2891 <entry>IMachine::getCPUIDLeafByOrdinal</entry>
2892 <entry><link linkend="IPlatformX86__getCPUIDLeafByOrdinal">IPlatformX86::getCPUIDLeafByOrdinal</link></entry>
2893 </row>
2894
2895 <row>
2896 <entry>IMachine::getCPUProperty</entry>
2897 <entry><link linkend="IPlatformX86__getCPUProperty">IPlatformX86::getCPUProperty</link></entry>
2898 </row>
2899
2900 <row>
2901 <entry>IMachine::getHWVirtExProperty</entry>
2902 <entry><link linkend="IPlatformX86__getHWVirtExProperty">IPlatformX86::getHWVirtExProperty</link></entry>
2903 </row>
2904
2905 <row>
2906 <entry>IMachine::removeAllCPUIDLeaves</entry>
2907 <entry><link linkend="IPlatformX86__removeAllCPUIDLeaves">IPlatformX86::removeAllCPUIDLeaves</link></entry>
2908 </row>
2909
2910 <row>
2911 <entry>IMachine::removeCPUIDLeaf</entry>
2912 <entry><link linkend="IPlatformX86__removeCPUIDLeaf">IPlatformX86::removeCPUIDLeaf</link></entry>
2913 </row>
2914
2915 <row>
2916 <entry>IMachine::setCPUIDLeaf</entry>
2917 <entry><link linkend="IPlatformX86__setCPUIDLeaf">IPlatformX86::setCPUIDLeaf</link></entry>
2918 </row>
2919
2920 <row>
2921 <entry>IMachine::setCPUProperty</entry>
2922 <entry><link linkend="IPlatformX86__setCPUProperty">IPlatformX86::setCPUProperty</link></entry>
2923 </row>
2924
2925 <row>
2926 <entry>IMachine::setHWVirtExProperty</entry>
2927 <entry><link linkend="IPlatformX86__setHWVirtExProperty">IPlatformX86::setHWVirtExProperty</link></entry>
2928 </row>
2929
2930 </tbody>
2931 </tgroup>
2932 </table>
2933
2934 <para>An itemized breakdown of the changes made to the Main API for ARM64 support is described below.</para>
2935
2936 <sect2>
2937 <title>Changes to Classes (Interfaces)</title>
2938
2939 <sect3>
2940 <title>New Classes (Interfaces) Added</title>
2941
2942 <itemizedlist>
2943 <listitem>
2944 <para><link linkend="IPlatform">IPlatform</link></para>
2945 <para>An umbrella-like interface containing a collection of properties and attributes
2946 of the software environment of the VM.</para>
2947 </listitem>
2948 <listitem>
2949 <para><link linkend="IPlatformX86">IPlatformX86</link></para>
2950 <para>An interface containing the x86-specific properties of the software
2951 environment of the VM.</para>
2952 </listitem>
2953 <listitem>
2954 <para><link linkend="IPlatformARM">IPlatformARM</link></para>
2955 <para>An interface containing the ARM-specific properties of the software
2956 environment of the VM.</para>
2957 </listitem>
2958 <listitem>
2959 <para><link linkend="IPlatformProperties">IPlatformProperties</link></para>
2960 <para>An interface containing the properties specific to the platform of the VM.</para>
2961 </listitem>
2962 <listitem>
2963 <para><link linkend="IHostX86">IHostX86</link></para>
2964 <para>An interface which provides further classification of the x86-specific
2965 properties of the physical host machine.</para>
2966 </listitem>
2967 </itemizedlist>
2968 </sect3>
2969
2970 <sect3>
2971 <title>Classes (Interfaces) Renamed</title>
2972
2973 <table>
2974 <title>Classes (Interfaces) Renamed</title>
2975 <tgroup cols="2" style="verywide">
2976 <tbody>
2977 <row>
2978 <entry><emphasis role="bold">Original Class Name</emphasis></entry>
2979 <entry><emphasis role="bold">New Class Name</emphasis></entry>
2980 </row>
2981 <row>
2982 <entry>IBIOSSettings</entry>
2983 <entry><link linkend="IFirmwareSettings">IFirmwareSettings</link></entry>
2984 </row>
2985 </tbody>
2986 </tgroup>
2987 </table>
2988 <para>The IBIOSSettings interface has been renamed to the more platform-neutral IFirmwareSettings.</para>
2989
2990 </sect3>
2991
2992 <sect3>
2993 <title>New Methods Added to Classes (Interfaces)</title>
2994 <itemizedlist>
2995 <listitem>
2996 <para><link
2997 linkend="IPlatformProperties">IPlatformProperties</link> <link linkend="IVirtualBox__getPlatformProperties">IVirtualBox::getPlatformProperties</link></para>
2998 <para>The new IVirtualBox::getPlatformProperties method returns
2999 an IPlatformProperties object which contains the platform-specific
3000 properties of a VM as described above.</para>
3001 </listitem>
3002 </itemizedlist>
3003 </sect3>
3004
3005 <sect3>
3006 <title>New Attributes Added to Classes (Interfaces)</title>
3007 <itemizedlist>
3008 <listitem>
3009 <para><link linkend="IPlatformProperties">IPlatformProperties</link><link linkend="ISystemProperties__platform">
3010 ISystemProperties::platform</link></para>
3011 <para>The ISystemProperties interface gets a new <emphasis>platform</emphasis>
3012 attribute which returns an IPlatformProperties object which contains the
3013 platform-specific properties of a VM as described above.</para>
3014 </listitem>
3015 <listitem>
3016 <para><link linkend="FirmwareType">FirmwareType</link> <link linkend="IFirmwareSettings__firmwareType">IFirmwareSettings::firmwareType</link></para>
3017 <para>The new IFirmwareSettings interface (renamed from IBIOSSettings) gets a new
3018 <emphasis>firmwareType</emphasis> attribute which returns a FirmwareType enumeration which
3019 contains the VM's firmware type.</para>
3020 </listitem>
3021 <listitem>
3022 <para><link linkend="PlatformArchitecture">PlatformArchitecture</link> <link linkend="IHost__architecture">IHost::architecture</link></para>
3023 <para>The IHost interface gets a new <emphasis>architecture</emphasis>
3024 attribute which returns a PlatformArchitecture enumeration which contains the
3025 platform's architecture.</para>
3026 </listitem>
3027 <listitem>
3028 <para><link linkend="IHostX86">IHostX86</link> <link linkend="IHost__x86">IHost::x86</link></para>
3029 <para>The IHost interface gets a new <emphasis>x86</emphasis>
3030 attribute which returns an IHostX86 object which contains the
3031 x86-specific properties of the physical host machine.</para>
3032 </listitem>
3033 <listitem>
3034 <para><link linkend="IPlatform">IPlatform</link> <link linkend="IMachine__platform">IMachine::platform</link></para>
3035 <para>The IMachine interface gets a new <emphasis>platform</emphasis>
3036 attribute which returns an IPlatform object which contains the
3037 properties related to the platform of the VM.</para>
3038 </listitem>
3039 <listitem>
3040 <para><link linkend="IFirmwareSettings">IFirmwareSettings</link> <link linkend="IMachine__firmwareSettings">IMachine::firmwareSettings</link></para>
3041 <para>The IMachine interface gets a new <emphasis>firmwareSettings</emphasis>
3042 attribute which returns an IFirmWareSettings object which contains the
3043 properties related to the platform of the VM.</para>
3044 </listitem>
3045 </itemizedlist>
3046 </sect3>
3047
3048 <sect3>
3049 <title>Class (Interface) Attribute Changes</title>
3050
3051 <table>
3052 <title>Classes Renamed</title>
3053 <tgroup cols="2" style="verywide">
3054 <tbody>
3055 <row>
3056 <entry><emphasis role="bold">Original Class Name</emphasis></entry>
3057 <entry><emphasis role="bold">New Class Name</emphasis></entry>
3058 </row>
3059 <row>
3060 <entry>BIOSBootMenuMode IBIOSSettings::bootMenuMode</entry>
3061 <entry><link linkend="FirmwareBootMenuMode">FirmwareBootMenuMode</link><link linkend="IFirmwareSettings__bootMenuMode"> IFirmwareSettings::bootMenuMode</link></entry>
3062 </row>
3063 </tbody>
3064 </tgroup>
3065 </table>
3066
3067 <para>The IBIOSSettings::bootMenuMode attribute has been moved to the new
3068 IFirmwareSettings interface and now returns the firmware boot menu mode in
3069 the new <link linkend="FirmwareBootMenuMode">FirmwareBootMenuMode</link> enumeration.</para>
3070
3071 <table>
3072 <title>Classes Renamed</title>
3073 <tgroup cols="2" style="verywide">
3074 <tbody>
3075 <row>
3076 <entry><emphasis role="bold">Original Class Name</emphasis></entry>
3077 <entry><emphasis role="bold">New Class Name</emphasis></entry>
3078 </row>
3079 <row>
3080 <entry>unsigned long ISerialPort::IOBase</entry>
3081 <entry>unsigned long <link linkend="ISerialPort__IOAddress">ISerialPort::IOAddress</link></entry>
3082 </row>
3083 </tbody>
3084 </tgroup>
3085 </table>
3086
3087 <para>The ISerialPort::IOBase attribute has been renamed to ISerialPort::IOAddress.</para>
3088
3089 </sect3>
3090
3091 </sect2>
3092
3093 <sect2>
3094 <title>Changes to Enumerations</title>
3095
3096 <sect3>
3097 <title>New Enumerations Added</title>
3098 <itemizedlist>
3099 <listitem>
3100 <para><link linkend="PlatformArchitecture">PlatformArchitecture</link></para>
3101 <para>The new PlatformArchitecture enumeration contains the CPU
3102 architecture type of the VM.</para>
3103 </listitem>
3104 </itemizedlist>
3105 </sect3>
3106
3107 <sect3>
3108 <title>New Enumerations Values</title>
3109 <itemizedlist>
3110 <listitem>
3111 <para><link linkend="CPUArchitecture">CPUArchitecture</link>
3112 <itemizedlist>
3113 <listitem><para><link linkend="CPUArchitecture__ARMv8_32">ARMv8_32</link></para></listitem>
3114 <listitem><para><link linkend="CPUArchitecture__ARMv8_64">ARMv8_64</link></para></listitem>
3115 </itemizedlist>
3116 </para>
3117 <para>The CPUArchitecture enumeration gets two new additions corresponding
3118 to 32-bit and 64-bit ARMv8 CPUs respectively.</para>
3119 </listitem>
3120 <listitem>
3121 <para><link linkend="AudioControllerType">AudioControllerType</link>
3122 <itemizedlist>
3123 <listitem><para><link linkend="AudioControllerType__VirtioSound">VirtioSound</link></para></listitem>
3124 </itemizedlist>
3125 </para>
3126 <para>The AudioControllerType enumeration gets a new value named <emphasis>VirtioSound</emphasis>.
3127 </para>
3128 </listitem>
3129 <listitem>
3130 <para><link linkend="ChipsetType">ChipsetType</link>
3131 <itemizedlist>
3132 <listitem><para><link linkend="ChipsetType__ARMv8Virtual">ARMv8Virtual</link></para></listitem>
3133 </itemizedlist>
3134 </para>
3135 <para>The ChipsetType enumeration gets a new value named <emphasis>ARMv8Virtual</emphasis>.
3136 </para>
3137 </listitem>
3138 </itemizedlist>
3139 </sect3>
3140
3141 <sect3>
3142 <title>Enumerations Renamed</title>
3143
3144 <table>
3145 <title>Enumerations Renamed</title>
3146 <tgroup cols="2" style="verywide">
3147 <tbody>
3148 <row>
3149 <entry><emphasis role="bold">Original Enumeration Name</emphasis></entry>
3150 <entry><emphasis role="bold">New Enumeration Name</emphasis></entry>
3151 </row>
3152 <row>
3153 <entry>CPUPropertyType</entry>
3154 <entry><link linkend="CPUPropertyTypeX86">CPUPropertyTypeX86</link></entry>
3155 </row>
3156 </tbody>
3157 </tgroup>
3158 </table>
3159
3160 <para>The CPUPropertyType enumeration has been renamed to CPUPropertyTypeX86.</para>
3161
3162 <table>
3163 <title>Enumerations Renamed</title>
3164 <tgroup cols="2" style="verywide">
3165 <tbody>
3166 <row>
3167 <entry><emphasis role="bold">Original Enumeration Name</emphasis></entry>
3168 <entry><emphasis role="bold">New Enumeration Name</emphasis></entry>
3169 </row>
3170 <row>
3171 <entry>BIOSBootMenuMode</entry>
3172 <entry><link linkend="FirmwareBootMenuMode">FirmwareBootMenuMode</link></entry>
3173 </row>
3174 </tbody>
3175 </tgroup>
3176 </table>
3177
3178 <para>The BIOSBootMenuMode enumeration has been renamed to FirmwareBootMenuMode.</para>
3179
3180 </sect3>
3181 </sect2>
3182 </sect1>
3183
3184 </chapter>
3185
3186 <xi:include href="SDKRef_apiref.xml" xpointer="xpointer(/book/*)"
3187 xmlns:xi="http://www.w3.org/2001/XInclude" />
3188
3189 <chapter id="cloud">
3190 <title>Working with the Cloud</title>
3191
3192 <para>VirtualBox supports and goes towards the Oracle tendencies like "move to the Cloud".</para>
3193
3194 <sect1>
3195 <title>OCI features</title>
3196 <para>VirtualBox supports the Oracle Cloud Infrastructure (OCI). See the interfaces:
3197 <link linkend="ICloudClient">ICloudClient</link>,
3198 <link linkend="ICloudProvider">ICloudProvider</link>,
3199 <link linkend="ICloudProfile">ICloudProfile</link>,
3200 <link linkend="ICloudProviderManager">ICloudProviderManager</link>.
3201 </para>
3202 <para>Each cloud interface has own implementation to support OCI features. There are everal functions in the implementation
3203 which should be explained in details because OCI requires some special data or settings.
3204 </para>
3205 <para>
3206 Also see the enumeration <link linkend="VirtualSystemDescriptionType">VirtualSystemDescriptionType</link> for the possible values.
3207 </para>
3208 </sect1>
3209
3210 <sect1>
3211 <title>Function ICloudClient::exportVM</title>
3212 <para>
3213 See the <link linkend="ICloudClient__exportVM">ICloudClient::exportVM</link>.
3214 The function exports an existing virtual machine into OCI. The final result of this operation is creation a custom image
3215 from the bootable image of VM. The Id of created image is returned in the parameter "description" (which is
3216 <link linkend="IVirtualSystemDescription">IVirtualSystemDescription</link>) as an entry with the type
3217 VirtualSystemDescriptionType::CloudImageId. The standard steps here are:
3218 <itemizedlist>
3219 <listitem>
3220 <para>Upload VBox image to OCI Object Storage.</para>
3221 </listitem>
3222 <listitem>
3223 <para>Create OCI custom image from the uploaded object.</para>
3224 </listitem>
3225 </itemizedlist>
3226 Parameter "description" must contain all information and settings needed for creation a custom image in OCI.
3227 At least next entries must be presented there before the call:
3228 <itemizedlist>
3229 <listitem>
3230 <para>VirtualSystemDescriptionType::Name - Name of new instance in OCI.</para>
3231 </listitem>
3232 <listitem>
3233 <para>VirtualSystemDescriptionType::HardDiskImage - The local path or id of bootable VM image.</para>
3234 </listitem>
3235 <listitem>
3236 <para>VirtualSystemDescriptionType::CloudBucket - A cloud bucket name where the exported image is uploaded.</para>
3237 </listitem>
3238 <listitem>
3239 <para>VirtualSystemDescriptionType::CloudImageDisplayName - A name which is assigned to a new custom image in the OCI.</para>
3240 </listitem>
3241 <listitem>
3242 <para>VirtualSystemDescriptionType::CloudKeepObject - Whether keep or delete an uploaded object after its usage.</para>
3243 </listitem>
3244 <listitem>
3245 <para>VirtualSystemDescriptionType::CloudLaunchInstance - Whether launch or not a new instance.</para>
3246 </listitem>
3247 </itemizedlist>
3248 </para>
3249 </sect1>
3250
3251 <sect1>
3252 <title>Function ICloudClient::launchVM</title>
3253 <para>
3254 See the <link linkend="ICloudClient__launchVM">ICloudClient::launchVM</link>.
3255 The function launches a new instance in OCI with a bootable volume previously created from a custom image in OCI or
3256 as the source may be used an existing bootable volume which shouldn't be attached to any instance.
3257 For launching instance from a custom image use the parameter VirtualSystemDescriptionType::CloudImageId.
3258 For launching instance from a bootable volume use the parameter VirtualSystemDescriptionType::CloudBootVolumeId.
3259 Only one of them must be presented otherwise the error will occur.
3260 The final result of this operation is a running instance. The id of created instance is returned
3261 in the parameter "description" (which is <link linkend="IVirtualSystemDescription">IVirtualSystemDescription</link>)
3262 as an entry with the type VirtualSystemDescriptionType::CloudInstanceId. Parameter "description" must contain all information
3263 and settings needed for creation a new instance in OCI. At least next entries must be presented there before the call:
3264 <itemizedlist>
3265 <listitem>
3266 <para>VirtualSystemDescriptionType::Name - Name of new instance in OCI.</para>
3267 </listitem>
3268 <listitem>
3269 <para>VirtualSystemDescriptionType::CloudOCISubnet - OCID of existing subnet in OCI which will be used by the instance.</para>
3270 </listitem>
3271 <listitem>
3272 <para>
3273 Use VirtualSystemDescriptionType::CloudImageId - OCID of custom image used as a bootable image for the instance
3274 or
3275 VirtualSystemDescriptionType::CloudBootVolumeId - OCID of existing and non-attached bootable volume used as a bootable volume for the instance.
3276 </para>
3277 </listitem>
3278 <listitem>
3279 <para>Add VirtualSystemDescriptionType::CloudBootDiskSize - The size of instance bootable volume in GB,
3280 If you use VirtualSystemDescriptionType::CloudImageId.</para>
3281 </listitem>
3282 <listitem>
3283 <para>VirtualSystemDescriptionType::CloudInstanceShape - The shape of instance according to OCI documentation,
3284 defines the number of CPUs and RAM memory.</para>
3285 </listitem>
3286 <listitem>
3287 <para>VirtualSystemDescriptionType::CloudLaunchInstance - Whether launch or not a new instance.</para>
3288 </listitem>
3289 <listitem>
3290 <para>VirtualSystemDescriptionType::CloudDomain - Availability domain in OCI where new instance is created.</para>
3291 </listitem>
3292 <listitem>
3293 <para>VirtualSystemDescriptionType::CloudPublicIP - Whether the instance will have a public IP or not.</para>
3294 </listitem>
3295 <listitem>
3296 <para>VirtualSystemDescriptionType::CloudPublicSSHKey - Public SSH key which is used to connect to an instance via SSH.
3297 It may be one or more records with the type VirtualSystemDescriptionType::CloudPublicSSHKey in the VirtualSystemDescription.
3298 But at least one should be presented otherwise user won't be able to connect to the instance via SSH.
3299 </para>
3300 </listitem>
3301 </itemizedlist>
3302 </para>
3303 </sect1>
3304
3305 <sect1>
3306 <title>Function ICloudClient::getInstanceInfo</title>
3307 <para>
3308 See the <link linkend="ICloudClient__getInstanceInfo">ICloudClient::getInstanceInfo</link>.
3309 The function takes an instance id (parameter "uid"), finds the requested instance in OCI and gets back information
3310 about the found instance in the parameter "description" (which is <link linkend="IVirtualSystemDescription">IVirtualSystemDescription</link>)
3311 The entries with next types will be presented in the object:
3312 <itemizedlist>
3313 <listitem>
3314 <para>VirtualSystemDescriptionType::Name - Displayed name of the instance.</para>
3315 </listitem>
3316 <listitem>
3317 <para>VirtualSystemDescriptionType::CloudDomain - Availability domain in OCI.</para>
3318 </listitem>
3319 <listitem>
3320 <para>VirtualSystemDescriptionType::CloudImageId - Name of custom image used for creation this instance.</para>
3321 </listitem>
3322 <listitem>
3323 <para>VirtualSystemDescriptionType::CloudInstanceId - The OCID of the instance.</para>
3324 </listitem>
3325 <listitem>
3326 <para>VirtualSystemDescriptionType::OS - Guest OS type of the instance.</para>
3327 </listitem>
3328 <listitem>
3329 <para>VirtualSystemDescriptionType::CloudBootDiskSize - Size of instance bootable image.</para>
3330 </listitem>
3331 <listitem>
3332 <para>VirtualSystemDescriptionType::CloudInstanceState - The instance state according to OCI documentation.</para>
3333 </listitem>
3334 <listitem>
3335 <para>VirtualSystemDescriptionType::CloudInstanceShape - The instance shape according to OCI documentation</para>
3336 </listitem>
3337 <listitem>
3338 <para>VirtualSystemDescriptionType::Memory - RAM memory in GB allocated for the instance.</para>
3339 </listitem>
3340 <listitem>
3341 <para>VirtualSystemDescriptionType::CPU - Number of virtual CPUs allocated for the instance.</para>
3342 </listitem>
3343 </itemizedlist>
3344 </para>
3345 </sect1>
3346
3347 <sect1>
3348 <title>Function ICloudClient::importInstance</title>
3349 <para>
3350 See the <link linkend="ICloudClient__importInstance">ICloudClient::importInstance</link>.
3351 The API function imports an existing instance from the OCI to the local host.
3352 The standard steps here are:
3353 <itemizedlist>
3354 <listitem>
3355 <para>Create a custom image from an existing OCI instance.</para>
3356 </listitem>
3357 <listitem>
3358 <para>Export the custom image to OCI object (the object is created in the OCI Object Storage).</para>
3359 </listitem>
3360 <listitem>
3361 <para>Download the OCI object to the local host.</para>
3362 </listitem>
3363 </itemizedlist>
3364 As the result of operation user will have a file with the suffix ".oci" on the local host. This file is a TAR archive which
3365 contains a bootable instance image in QCOW2 format and a JSON file with some metadata related to
3366 the imported instance. The function takes the parameter "description"
3367 (which is <link linkend="IVirtualSystemDescription">IVirtualSystemDescription</link>)
3368 Parameter "description" must contain all information and settings needed for successful operation result.
3369 At least next entries must be presented there before the call:
3370 <itemizedlist>
3371 <listitem>
3372 <para>VirtualSystemDescriptionType::Name is used for the several purposes:
3373 <itemizedlist>
3374 <listitem>
3375 <para>As a custom image name. A custom image is created from an instance.</para>
3376 </listitem>
3377 <listitem>
3378 <para>As OCI object name. An object is a file in OCI Object Storage. The object is created from the custom image.</para>
3379 </listitem>
3380 <listitem>
3381 <para>Name of imported instance on the local host. Because the result of import is a file, the file will have this
3382 name and extension ".oci".</para>
3383 </listitem>
3384 </itemizedlist>
3385 </para>
3386 </listitem>
3387 <listitem>
3388 <para>VirtualSystemDescriptionType::CloudInstanceId - The OCID of the existing instance.</para>
3389 </listitem>
3390 <listitem>
3391 <para>VirtualSystemDescriptionType::CloudBucket - a cloud bucket name in OCI Object Storage where created an OCI object
3392 from a custom image.
3393 </para>
3394 </listitem>
3395 </itemizedlist>
3396 </para>
3397 </sect1>
3398
3399 </chapter>
3400
3401 <chapter id="hgcm">
3402 <title>Host-Guest Communication Manager</title>
3403
3404 <para>The VirtualBox Host-Guest Communication Manager (HGCM) allows a
3405 guest application or a guest driver to call a host shared library. The
3406 following features of VirtualBox are implemented using HGCM: <itemizedlist>
3407 <listitem>
3408 <para>Shared Folders</para>
3409 </listitem>
3410
3411 <listitem>
3412 <para>Shared Clipboard</para>
3413 </listitem>
3414
3415 <listitem>
3416 <para>Guest configuration interface</para>
3417 </listitem>
3418 </itemizedlist></para>
3419
3420 <para>The shared library on the host contains a so called HGCM service.
3421 The guest HGCM client establishes a connection to the HGCM service on the
3422 host in order to call that HGCM service's entry point. When calling an
3423 HGCM service the client supplies a function code, the number of parameters
3424 for the function, and an array of the parameter arguments.</para>
3425
3426 <sect1>
3427 <title>Virtual hardware implementation</title>
3428
3429 <para>HGCM uses the Virtual Machine Monitor (VMM) virtual PCI device to
3430 exchange data between the guest and the host. The guest always acts as an
3431 initiator of requests. A request is constructed in the guest's physical
3432 memory which must be locked by the guest. The physical address is passed
3433 to the VMM device using a 32-bit
3434 <computeroutput>out edx, eax</computeroutput>
3435 instruction. The physical memory must be allocated below 4GB on 64-bit
3436 guests.</para>
3437
3438 <para>The host parses the request header and data and queues the request
3439 for the corresponding host HGCM service type. The guest continues
3440 execution and usually waits on an HGCM event semaphore.</para>
3441
3442 <para>When the request has been processed by the HGCM service, the VMM
3443 device sets the completion flag in the request header, sets the HGCM
3444 event and raises an IRQ for the guest. The IRQ handler signals the HGCM
3445 event semaphore and all HGCM callers check the completion flag in the
3446 corresponding request header. If the flag is set, the request is
3447 considered completed.</para>
3448 </sect1>
3449
3450 <sect1>
3451 <title>Protocol specification</title>
3452
3453 <para>The HGCM protocol definitions are contained in the
3454 <computeroutput>VBox/VBoxGuest.h</computeroutput> header file.</para>
3455
3456 <sect2>
3457 <title>Request header</title>
3458
3459 <para>HGCM request structures contains a generic header
3460 (VMMDevHGCMRequestHeader): <table>
3461 <title>HGCM Request Generic Header</title>
3462
3463 <tgroup cols="2">
3464 <tbody>
3465 <row>
3466 <entry><emphasis role="bold">Name</emphasis></entry>
3467
3468 <entry><emphasis role="bold">Description</emphasis></entry>
3469 </row>
3470
3471 <row>
3472 <entry>size</entry>
3473
3474 <entry>Size of the entire request.</entry>
3475 </row>
3476
3477 <row>
3478 <entry>version</entry>
3479
3480 <entry>Version of the header, must be set to
3481 <computeroutput>0x10001</computeroutput>.</entry>
3482 </row>
3483
3484 <row>
3485 <entry>type</entry>
3486
3487 <entry>Type of the request.</entry>
3488 </row>
3489
3490 <row>
3491 <entry>rc</entry>
3492
3493 <entry>HGCM return code, which will be set by the VMM
3494 device.</entry>
3495 </row>
3496
3497 <row>
3498 <entry>reserved1</entry>
3499
3500 <entry>A reserved field 1.</entry>
3501 </row>
3502
3503 <row>
3504 <entry>reserved2</entry>
3505
3506 <entry>A reserved field 2.</entry>
3507 </row>
3508
3509 <row>
3510 <entry>flags</entry>
3511
3512 <entry>HGCM flags, set by the VMM device.</entry>
3513 </row>
3514
3515 <row>
3516 <entry>result</entry>
3517
3518 <entry>The HGCM result code, set by the VMM device.</entry>
3519 </row>
3520 </tbody>
3521 </tgroup>
3522 </table> <note>
3523 <itemizedlist>
3524 <listitem>
3525 <para>All fields are 32-bit.</para>
3526 </listitem>
3527
3528 <listitem>
3529 <para>Fields from <computeroutput>size</computeroutput> to
3530 <computeroutput>reserved2</computeroutput> are a standard VMM
3531 device request header, which is used for other interfaces as
3532 well.</para>
3533 </listitem>
3534 </itemizedlist>
3535 </note></para>
3536
3537 <para>The <emphasis role="bold">type</emphasis> field indicates the
3538 type of the HGCM request: <table>
3539 <title>Request Types</title>
3540
3541 <tgroup cols="2">
3542 <tbody>
3543 <row>
3544 <entry><emphasis role="bold">Name (decimal
3545 value)</emphasis></entry>
3546
3547 <entry><emphasis role="bold">Description</emphasis></entry>
3548 </row>
3549
3550 <row>
3551 <entry>VMMDevReq_HGCMConnect
3552 (<computeroutput>60</computeroutput>)</entry>
3553
3554 <entry>Connect to an HGCM service.</entry>
3555 </row>
3556
3557 <row>
3558 <entry>VMMDevReq_HGCMDisconnect
3559 (<computeroutput>61</computeroutput>)</entry>
3560
3561 <entry>Disconnect from the service.</entry>
3562 </row>
3563
3564 <row>
3565 <entry>VMMDevReq_HGCMCall32
3566 (<computeroutput>62</computeroutput>)</entry>
3567
3568 <entry>Call an HGCM function using the 32-bit
3569 interface.</entry>
3570 </row>
3571
3572 <row>
3573 <entry>VMMDevReq_HGCMCall64
3574 (<computeroutput>63</computeroutput>)</entry>
3575
3576 <entry>Call an HGCM function using the 64-bit
3577 interface.</entry>
3578 </row>
3579
3580 <row>
3581 <entry>VMMDevReq_HGCMCancel
3582 (<computeroutput>64</computeroutput>)</entry>
3583
3584 <entry>Cancel an HGCM request currently being processed by a
3585 host HGCM service.</entry>
3586 </row>
3587 </tbody>
3588 </tgroup>
3589 </table></para>
3590
3591 <para>The <emphasis role="bold">flags</emphasis> field may contain:
3592 <table>
3593 <title>Flags</title>
3594
3595 <tgroup cols="2">
3596 <tbody>
3597 <row>
3598 <entry><emphasis role="bold">Name (hexadecimal
3599 value)</emphasis></entry>
3600
3601 <entry><emphasis role="bold">Description</emphasis></entry>
3602 </row>
3603
3604 <row>
3605 <entry>VBOX_HGCM_REQ_DONE
3606 (<computeroutput>0x00000001</computeroutput>)</entry>
3607
3608 <entry>The request has been processed by the host
3609 service.</entry>
3610 </row>
3611
3612 <row>
3613 <entry>VBOX_HGCM_REQ_CANCELLED
3614 (<computeroutput>0x00000002</computeroutput>)</entry>
3615
3616 <entry>This request was cancelled.</entry>
3617 </row>
3618 </tbody>
3619 </tgroup>
3620 </table></para>
3621 </sect2>
3622
3623 <sect2>
3624 <title>Connect</title>
3625
3626 <para>The connection request must be issued by the guest HGCM client
3627 before it can call the HGCM service (VMMDevHGCMConnect): <table>
3628 <title>Connect request</title>
3629
3630 <tgroup cols="2">
3631 <tbody>
3632 <row>
3633 <entry><emphasis role="bold">Name</emphasis></entry>
3634
3635 <entry><emphasis role="bold">Description</emphasis></entry>
3636 </row>
3637
3638 <row>
3639 <entry>header</entry>
3640
3641 <entry>The generic HGCM request header with type equal to
3642 VMMDevReq_HGCMConnect
3643 (<computeroutput>60</computeroutput>).</entry>
3644 </row>
3645
3646 <row>
3647 <entry>type</entry>
3648
3649 <entry>The type of the service location information (32
3650 bit).</entry>
3651 </row>
3652
3653 <row>
3654 <entry>location</entry>
3655
3656 <entry>The service location information (128 bytes).</entry>
3657 </row>
3658
3659 <row>
3660 <entry>clientId</entry>
3661
3662 <entry>The client identifier assigned to the connecting
3663 client by the HGCM subsystem (32-bit).</entry>
3664 </row>
3665 </tbody>
3666 </tgroup>
3667 </table> The <emphasis role="bold">type</emphasis> field tells the
3668 HGCM how to look for the requested service: <table>
3669 <title>Location Information Types</title>
3670
3671 <tgroup cols="2">
3672 <tbody>
3673 <row>
3674 <entry><emphasis role="bold">Name (hexadecimal
3675 value)</emphasis></entry>
3676
3677 <entry><emphasis role="bold">Description</emphasis></entry>
3678 </row>
3679
3680 <row>
3681 <entry>VMMDevHGCMLoc_LocalHost
3682 (<computeroutput>0x1</computeroutput>)</entry>
3683
3684 <entry>The requested service is a shared library located on
3685 the host and the location information contains the library
3686 name.</entry>
3687 </row>
3688
3689 <row>
3690 <entry>VMMDevHGCMLoc_LocalHost_Existing
3691 (<computeroutput>0x2</computeroutput>)</entry>
3692
3693 <entry>The requested service is a preloaded one and the
3694 location information contains the service name.</entry>
3695 </row>
3696 </tbody>
3697 </tgroup>
3698 </table> <note>
3699 <para>Currently preloaded HGCM services are hard-coded in
3700 VirtualBox: <itemizedlist>
3701 <listitem>
3702 <para>VBoxSharedFolders</para>
3703 </listitem>
3704
3705 <listitem>
3706 <para>VBoxSharedClipboard</para>
3707 </listitem>
3708
3709 <listitem>
3710 <para>VBoxGuestPropSvc</para>
3711 </listitem>
3712
3713 <listitem>
3714 <para>VBoxSharedOpenGL</para>
3715 </listitem>
3716 </itemizedlist></para>
3717 </note> There is no difference between both types of HGCM services,
3718 only the location mechanism is different.</para>
3719
3720 <para>The client identifier is returned by the host and must be used
3721 in all subsequent requests by the client.</para>
3722 </sect2>
3723
3724 <sect2>
3725 <title>Disconnect</title>
3726
3727 <para>This request disconnects the client and makes the client
3728 identifier invalid (VMMDevHGCMDisconnect): <table>
3729 <title>Disconnect request</title>
3730
3731 <tgroup cols="2">
3732 <tbody>
3733 <row>
3734 <entry><emphasis role="bold">Name</emphasis></entry>
3735
3736 <entry><emphasis role="bold">Description</emphasis></entry>
3737 </row>
3738
3739 <row>
3740 <entry>header</entry>
3741
3742 <entry>The generic HGCM request header with type equal to
3743 VMMDevReq_HGCMDisconnect
3744 (<computeroutput>61</computeroutput>).</entry>
3745 </row>
3746
3747 <row>
3748 <entry>clientId</entry>
3749
3750 <entry>The client identifier previously returned by the
3751 connect request (32-bit).</entry>
3752 </row>
3753 </tbody>
3754 </tgroup>
3755 </table></para>
3756 </sect2>
3757
3758 <sect2>
3759 <title>Call32 and Call64</title>
3760
3761 <para>Calls the HGCM service entry point (VMMDevHGCMCall) using 32-bit
3762 or 64-bit addresses: <table>
3763 <title>Call request</title>
3764
3765 <tgroup cols="2">
3766 <tbody>
3767 <row>
3768 <entry><emphasis role="bold">Name</emphasis></entry>
3769
3770 <entry><emphasis role="bold">Description</emphasis></entry>
3771 </row>
3772
3773 <row>
3774 <entry>header</entry>
3775
3776 <entry>The generic HGCM request header with type equal to
3777 either VMMDevReq_HGCMCall32
3778 (<computeroutput>62</computeroutput>) or
3779 VMMDevReq_HGCMCall64
3780 (<computeroutput>63</computeroutput>).</entry>
3781 </row>
3782
3783 <row>
3784 <entry>clientId</entry>
3785
3786 <entry>The client identifier previously returned by the
3787 connect request (32-bit).</entry>
3788 </row>
3789
3790 <row>
3791 <entry>function</entry>
3792
3793 <entry>The function code to be processed by the service (32
3794 bit).</entry>
3795 </row>
3796
3797 <row>
3798 <entry>cParms</entry>
3799
3800 <entry>The number of following parameters (32-bit). This
3801 value is 0 if the function requires no parameters.</entry>
3802 </row>
3803
3804 <row>
3805 <entry>parms</entry>
3806
3807 <entry>An array of parameter description structures
3808 (HGCMFunctionParameter32 or
3809 HGCMFunctionParameter64).</entry>
3810 </row>
3811 </tbody>
3812 </tgroup>
3813 </table></para>
3814
3815 <para>The 32-bit parameter description (HGCMFunctionParameter32)
3816 consists of a 32-bit type field and 8 bytes of an opaque value, so 12
3817 bytes in total. The 64-bit variant (HGCMFunctionParameter64) consists
3818 of the 32-bit type and 12 bytes of a value, so 16 bytes in total.</para>
3819
3820 <para><table>
3821 <title>Parameter types</title>
3822
3823 <tgroup cols="2">
3824 <tbody>
3825 <row>
3826 <entry><emphasis role="bold">Type</emphasis></entry>
3827
3828 <entry><emphasis role="bold">Format of the
3829 value</emphasis></entry>
3830 </row>
3831
3832 <row>
3833 <entry>VMMDevHGCMParmType_32bit (1)</entry>
3834
3835 <entry>A 32-bit value.</entry>
3836 </row>
3837
3838 <row>
3839 <entry>VMMDevHGCMParmType_64bit (2)</entry>
3840
3841 <entry>A 64-bit value.</entry>
3842 </row>
3843
3844 <row>
3845 <entry>VMMDevHGCMParmType_PhysAddr (3)</entry>
3846
3847 <entry>A 32-bit size followed by a 32-bit or 64-bit guest
3848 physical address.</entry>
3849 </row>
3850
3851 <row>
3852 <entry>VMMDevHGCMParmType_LinAddr (4)</entry>
3853
3854 <entry>A 32-bit size followed by a 32-bit or 64-bit guest
3855 linear address. The buffer is used both for guest to host
3856 and for host to guest data.</entry>
3857 </row>
3858
3859 <row>
3860 <entry>VMMDevHGCMParmType_LinAddr_In (5)</entry>
3861
3862 <entry>Same as VMMDevHGCMParmType_LinAddr but the buffer is
3863 used only for host to guest data.</entry>
3864 </row>
3865
3866 <row>
3867 <entry>VMMDevHGCMParmType_LinAddr_Out (6)</entry>
3868
3869 <entry>Same as VMMDevHGCMParmType_LinAddr but the buffer is
3870 used only for guest to host data.</entry>
3871 </row>
3872
3873 <row>
3874 <entry>VMMDevHGCMParmType_LinAddr_Locked (7)</entry>
3875
3876 <entry>Same as VMMDevHGCMParmType_LinAddr but the buffer is
3877 already locked by the guest.</entry>
3878 </row>
3879
3880 <row>
3881 <entry>VMMDevHGCMParmType_LinAddr_Locked_In (1)</entry>
3882
3883 <entry>Same as VMMDevHGCMParmType_LinAddr_In but the buffer
3884 is already locked by the guest.</entry>
3885 </row>
3886
3887 <row>
3888 <entry>VMMDevHGCMParmType_LinAddr_Locked_Out (1)</entry>
3889
3890 <entry>Same as VMMDevHGCMParmType_LinAddr_Out but the buffer
3891 is already locked by the guest.</entry>
3892 </row>
3893 </tbody>
3894 </tgroup>
3895 </table></para>
3896
3897 </sect2>
3898
3899 <sect2>
3900 <title>Cancel</title>
3901
3902 <para>This request cancels a call request (VMMDevHGCMCancel): <table>
3903 <title>Cancel request</title>
3904
3905 <tgroup cols="2">
3906 <tbody>
3907 <row>
3908 <entry><emphasis role="bold">Name</emphasis></entry>
3909
3910 <entry><emphasis role="bold">Description</emphasis></entry>
3911 </row>
3912
3913 <row>
3914 <entry>header</entry>
3915
3916 <entry>The generic HGCM request header with type equal to
3917 VMMDevReq_HGCMCancel
3918 (<computeroutput>64</computeroutput>).</entry>
3919 </row>
3920 </tbody>
3921 </tgroup>
3922 </table></para>
3923 </sect2>
3924 </sect1>
3925
3926 <sect1>
3927 <title>Guest software interface</title>
3928
3929 <para>Guest HGCM clients can call HGCM services from both drivers
3930 and applications.</para>
3931
3932 <sect2>
3933 <title>The guest driver interface</title>
3934
3935 <para>The driver interface is implemented in the VirtualBox guest
3936 additions driver (VBoxGuest) which works with the VMM virtual device.
3937 Drivers must use the VBox Guest Library (VBGL) which provides an API
3938 for HGCM clients (<computeroutput>VBox/VBoxGuestLib.h</computeroutput>
3939 and <computeroutput>VBox/VBoxGuest.h</computeroutput>). The key VBGL API
3940 routines are as follows:</para>
3941
3942 <para><screen>
3943DECLR0VBGL(int) VbglR0HGCMConnect(VBGLHGCMHANDLE *pHandle, const char *pszServiceName, HGCMCLIENTID *pidClient);
3944 </screen> VbglR0HGCMConnect() connects to the HGCM service on the host. An
3945 example of a guest driver connecting to the VirtualBox Shared Folder
3946 HGCM service follows:<screen>
3947 VBoxGuestHGCMConnectInfo data;
3948
3949 memset(&amp;data, sizeof(VBoxGuestHGCMConnectInfo));
3950
3951 data.result = VINF_SUCCESS;
3952 data.Loc.type = VMMDevHGCMLoc_LocalHost_Existing;
3953 strcpy(data.Loc.u.host.achName, "VBoxSharedFolders");
3954
3955 rc = VbglR0HGCMConnect(&amp;handle, "VBoxSharedFolders"&amp;, data);
3956
3957 if (RT_SUCCESS(rc))
3958 {
3959 rc = data.result;
3960 }
3961
3962 if (RT_SUCCESS(rc))
3963 {
3964 /* Get the assigned client identifier. */
3965 ulClientID = data.u32ClientID;
3966 }
3967 </screen></para>
3968
3969 <para><screen>
3970DECLVBGL(int) VbglR0HGCMDisconnect(VBGLHGCMHANDLE handle, VBoxGuestHGCMDisconnectInfo *pData);
3971 </screen> VbglR0HGCMDisconnect() disconnects from the HGCM service on the
3972 host. An example of a guest driver disconnecting from an HGCM service
3973 using the client identifier from an earlier call to VbglR0HGCMConnect()
3974 follows:<screen>
3975 VBoxGuestHGCMDisconnectInfo data;
3976
3977 RtlZeroMemory(&amp;data, sizeof (VBoxGuestHGCMDisconnectInfo));
3978
3979 data.result = VINF_SUCCESS;
3980 data.u32ClientID = ulClientID;
3981
3982 rc = VbglR0HGCMDisconnect(handle, &amp;data);
3983 </screen></para>
3984
3985 <para><screen>
3986DECLVBGL(int) VbglR0HGCMCall(VBGLHGCMHANDLE handle, VBoxGuestHGCMCallInfo *pData, uint32_t cbData);
3987 </screen> VbglR0HGCMCall() calls a function specified in the
3988 VBoxGuestHGCMCallInfo argument in the HGCM service on the host. An
3989 example of a guest driver calling the Shared Folders HGCM service to
3990 issue a read of an object in a shared folder follows:<screen>
3991typedef struct _VBoxSFRead
3992{
3993 VBoxGuestHGCMCallInfo callInfo;
3994
3995 /** pointer, in: SHFLROOT
3996 * Root handle of the mapping which name is queried.
3997 */
3998 HGCMFunctionParameter root;
3999
4000 /** value64, in:
4001 * SHFLHANDLE of object to read from.
4002 */
4003 HGCMFunctionParameter handle;
4004
4005 /** value64, in:
4006 * Offset to read from.
4007 */
4008 HGCMFunctionParameter offset;
4009
4010 /** value64, in/out:
4011 * Bytes to read/How many were read.
4012 */
4013 HGCMFunctionParameter cb;
4014
4015 /** pointer, out:
4016 * Buffer to place data to.
4017 */
4018 HGCMFunctionParameter buffer;
4019
4020} VBoxSFRead;
4021
4022/** Number of parameters */
4023#define SHFL_CPARMS_READ (5)
4024
4025...
4026
4027 VBoxSFRead data;
4028
4029 /* The call information. */
4030 data.callInfo.result = VINF_SUCCESS; /* Will be returned by HGCM. */
4031 data.callInfo.u32ClientID = ulClientID; /* Client identifier. */
4032 data.callInfo.u32Function = SHFL_FN_READ; /* The function code. */
4033 data.callInfo.cParms = SHFL_CPARMS_READ; /* Number of parameters. */
4034
4035 /* Initialize parameters. */
4036 data.root.type = VMMDevHGCMParmType_32bit;
4037 data.root.u.value32 = pMap-&gt;root;
4038
4039 data.handle.type = VMMDevHGCMParmType_64bit;
4040 data.handle.u.value64 = hFile;
4041
4042 data.offset.type = VMMDevHGCMParmType_64bit;
4043 data.offset.u.value64 = offset;
4044
4045 data.cb.type = VMMDevHGCMParmType_32bit;
4046 data.cb.u.value32 = *pcbBuffer;
4047
4048 data.buffer.type = VMMDevHGCMParmType_LinAddr_Out;
4049 data.buffer.u.Pointer.size = *pcbBuffer;
4050 data.buffer.u.Pointer.u.linearAddr = (uintptr_t)pBuffer;
4051
4052 rc = VbglR0HGCMCall(handle, &amp;data.callInfo, sizeof (data));
4053
4054 if (RT_SUCCESS(rc))
4055 {
4056 rc = data.callInfo.result;
4057 *pcbBuffer = data.cb.u.value32; /* This is returned by the HGCM service. */
4058 }
4059 </screen></para>
4060 </sect2>
4061
4062 <sect2>
4063 <title>Guest application interface</title>
4064
4065 <para>Applications call the VirtualBox Guest Additions driver to
4066 utilize the HGCM interface. The following IOCTLs correspond to the
4067 <computeroutput>VbglR0HGCM*</computeroutput> functions listed above:
4068 <itemizedlist>
4069 <listitem>
4070 <para><computeroutput>VBGL_IOCTL_HGCM_CONNECT =>
4071 VbglR0HGCMConnect()</computeroutput></para>
4072 </listitem>
4073
4074 <listitem>
4075 <para><computeroutput>VBGL_IOCTL_HGCM_DISCONNECT =>
4076 VbglR0HGCMDisconnect()</computeroutput></para>
4077 </listitem>
4078
4079 <listitem>
4080 <para><computeroutput>VBGL_IOCTL_HGCM_CALL =>
4081 VbglR0HGCMCall()</computeroutput></para>
4082 </listitem>
4083 </itemizedlist></para>
4084
4085 <para>These IOCTLs get the same input buffer as the
4086 <computeroutput>VbglR0HGCM*</computeroutput> functions and the output
4087 buffer has the same format as the input buffer. The same address can
4088 be used for both the input and output buffers.</para>
4089 </sect2>
4090 </sect1>
4091
4092 <sect1>
4093 <title>HGCM Service Implementation</title>
4094
4095 <para>The HGCM service is a shared library with a specific set of entry
4096 points. The library must export the
4097 <computeroutput>VBoxHGCMSvcLoad</computeroutput> entry point: <screen>
4098extern "C" DECLCALLBACK(DECLEXPORT(int)) VBoxHGCMSvcLoad(VBOXHGCMSVCFNTABLE *ptable)
4099 </screen></para>
4100
4101 <para>The service must check the
4102 <computeroutput>ptable-&gt;cbSize</computeroutput> and
4103 <computeroutput>ptable-&gt;u32Version</computeroutput> fields of the
4104 input structure and fill in the remaining fields with function pointers of
4105 service entry points (listed below) and the size of the required client
4106 buffer size.</para>
4107
4108 <para>The HGCM service gets a dedicated thread which calls service
4109 entry points synchronously, thus the service entry point will only be called
4110 again once a previous call has returned. However, the guest calls can be
4111 processed asynchronously. Therefore the service must call a completion
4112 callback when the operation is actually completed. The callback can be
4113 issued from another thread as well.</para>
4114
4115 <para>Service entry points are listed in the
4116 <computeroutput>VBox/hgcmsvc.h</computeroutput> in the
4117 <computeroutput>VBOXHGCMSVCFNTABLE</computeroutput> structure. <table>
4118 <title>Service entry points</title>
4119
4120 <tgroup cols="2">
4121 <tbody>
4122 <row>
4123 <entry><emphasis role="bold">Entry Point</emphasis></entry>
4124
4125 <entry><emphasis role="bold">Description</emphasis></entry>
4126 </row>
4127
4128 <row>
4129 <entry>int pfnUnload(void *pvService)</entry>
4130
4131 <entry>The service is being unloaded.</entry>
4132 </row>
4133
4134 <row>
4135 <entry>int pfnConnect(void *pvService, uint32_t u32ClientID, void *pvClient,
4136 uint32_t fRequestor, bool fRestoring)</entry>
4137
4138 <entry>A client <computeroutput>u32ClientID</computeroutput>
4139 is connected to the service. The
4140 <computeroutput>pvClient</computeroutput> parameter points to
4141 an allocated memory buffer which can be used by the service to
4142 store the client information.</entry>
4143 </row>
4144
4145 <row>
4146 <entry>int pfnDisconnect(void *pvService, uint32_t u32ClientID,
4147 void *pvClient)</entry>
4148
4149 <entry>A client is being disconnected.</entry>
4150 </row>
4151
4152 <row>
4153 <entry>void pfnCall(void *pvService, VBOXHGCMCALLHANDLE callHandle,
4154 uint32_t u32ClientID, void *pvClient, uint32_t function,
4155 uint32_t cParms, VBOXHGCMSVCPARM paParms[],
4156 uint64_t tsArrival)</entry>
4157
4158 <entry>A guest client calls a service function. The
4159 <computeroutput>callHandle</computeroutput> must be used in
4160 the VBOXHGCMSVCHELPERS::pfnCallComplete callback when the call
4161 has been processed.</entry>
4162 </row>
4163
4164 <row>
4165 <entry>int pfnHostCall(void *pvService, uint32_t function, uint32_t cParms,
4166 VBOXHGCMSVCPARM paParms[])</entry>
4167
4168 <entry>Called by the VirtualBox host components to perform
4169 functions which should be not accessible by the guest. Usually
4170 this entry point is used by VirtualBox to configure the
4171 service.</entry>
4172 </row>
4173
4174 <row>
4175 <entry>int pfnSaveState(void *pvService, uint32_t u32ClientID, void *pvClient,
4176 PSSMHANDLE pSSM, PCVMMR3VTABLE pVMM)</entry>
4177
4178 <entry>The VM state is being saved and the service must save
4179 relevant information using the SSM API
4180 (<computeroutput>VBox/ssm.h</computeroutput>).</entry>
4181 </row>
4182
4183 <row>
4184 <entry>int pfnLoadState(void *pvService, uint32_t u32ClientID, void *pvClient,
4185 PSSMHANDLE pSSM, PCVMMR3VTABLE pVMM, uint32_t uVersion)</entry>
4186
4187 <entry>The VM is being restored from the saved state and the
4188 service must load the saved information and be able to
4189 continue operations from the saved state.</entry>
4190 </row>
4191 </tbody>
4192 </tgroup>
4193 </table></para>
4194 </sect1>
4195 </chapter>
4196
4197 <chapter id="rdpweb">
4198 <title>RDP Web Control</title>
4199
4200 <para>The VirtualBox <emphasis>RDP Web Control</emphasis> (RDPWeb)
4201 provides remote access to a running VM. RDPWeb is an RDP (Remote Desktop
4202 Protocol) client based on Flash technology and can be used from a Web
4203 browser with a Flash plugin.</para>
4204
4205 <sect1>
4206 <title>RDPWeb features</title>
4207
4208 <para>RDPWeb is embedded into a Web page and connects to a VRDP server
4209 in order to display the remote VM screen and pass keyboard and mouse events
4210 to the VM.</para>
4211 </sect1>
4212
4213 <sect1>
4214 <title>RDPWeb reference</title>
4215
4216 <para>RDPWeb consists of two required components:<itemizedlist>
4217 <listitem>
4218 <para>Flash movie file
4219 <computeroutput>RDPClientUI.swf</computeroutput></para>
4220 </listitem>
4221
4222 <listitem>
4223 <para>JavaScript helpers contained in
4224 <computeroutput>webclient.js</computeroutput></para>
4225 </listitem>
4226 </itemizedlist></para>
4227
4228 <para>The VirtualBox SDK contains sample HTML code
4229 including:<itemizedlist>
4230 <listitem>
4231 <para>A JavaScript library for embedding Flash content:
4232 <computeroutput>SWFObject.js</computeroutput></para>
4233 </listitem>
4234
4235 <listitem>
4236 <para>A sample HTML page:
4237 <computeroutput>webclient3.html</computeroutput></para>
4238 </listitem>
4239 </itemizedlist></para>
4240
4241 <sect2>
4242 <title>RDPWeb functions</title>
4243
4244 <para><computeroutput>RDPClientUI.swf</computeroutput> and
4245 <computeroutput>webclient.js</computeroutput> work together to provide the
4246 RDP Web Control functionality. The JavaScript code is responsible for
4247 proper Flash initialization, delivering mouse events to the Flash object,
4248 and processing resize requests from the Flash object. On the other hand,
4249 the SWF file contains a few JavaScript callable methods, which are used
4250 both from <computeroutput>webclient.js</computeroutput> and the user HTML
4251 page.</para>
4252
4253 <sect3>
4254 <title>JavaScript functions</title>
4255
4256 <para>The <computeroutput>webclient.js</computeroutput> file contains
4257 several helper JavaScript functions. In the following table ElementId
4258 refers to an HTML element name or attribute, and Element to the HTML
4259 element itself.
4260 The HTML code<programlisting>
4261 &lt;div id="FlashRDP"&gt;
4262 &lt;/div&gt;
4263</programlisting> would have ElementId equal to FlashRDP and Element equal to
4264 the div element.</para>
4265
4266 <para><itemizedlist>
4267 <listitem>
4268 <programlisting>RDPWebClient.embedSWF(SWFFileName, ElementId)</programlisting>
4269
4270 <para>Uses the open-source SWFObject library to replace the HTML
4271 element with the Flash movie.</para>
4272 </listitem>
4273
4274 <listitem>
4275 <programlisting>RDPWebClient.isRDPWebControlById(ElementId)</programlisting>
4276
4277 <para>Returns true if the given ElementId refers to an RDPWeb
4278 Flash element.</para>
4279 </listitem>
4280
4281 <listitem>
4282 <programlisting>RDPWebClient.isRDPWebControlByElement(Element)</programlisting>
4283
4284 <para>Returns true if the given Element is an RDPWeb Flash
4285 element.</para>
4286 </listitem>
4287
4288 <listitem>
4289 <programlisting>RDPWebClient.getFlashById(ElementId)</programlisting>
4290
4291 <para>Returns an element, which is referenced by the given
4292 ElementId. This function will try to resolve any element, even if
4293 it is not a Flash movie.</para>
4294 </listitem>
4295 </itemizedlist></para>
4296 </sect3>
4297
4298 <sect3>
4299 <title>Flash methods callable from JavaScript</title>
4300
4301 <para>The <computeroutput>RDPWebClienUI.swf</computeroutput> methods can
4302 be called directly from JavaScript code on an HTML page:</para>
4303
4304 <itemizedlist>
4305 <listitem>
4306 <para>getProperty(Name)</para>
4307 </listitem>
4308
4309 <listitem>
4310 <para>setProperty(Name)</para>
4311 </listitem>
4312
4313 <listitem>
4314 <para>connect()</para>
4315 </listitem>
4316
4317 <listitem>
4318 <para>disconnect()</para>
4319 </listitem>
4320
4321 <listitem>
4322 <para>keyboardSendCAD()</para>
4323 </listitem>
4324 </itemizedlist>
4325 </sect3>
4326
4327 <sect3>
4328 <title>Flash JavaScript callbacks</title>
4329
4330 <para><computeroutput>RDPWebClienUI.swf</computeroutput> calls
4331 JavaScript functions provided by the HTML page.</para>
4332 </sect3>
4333 </sect2>
4334
4335 <sect2>
4336 <title>Embedding RDPWeb in an HTML page</title>
4337
4338 <para>It is necessary to include the
4339 <computeroutput>webclient.js</computeroutput> helper script. If
4340 the SWFObject library is used, the
4341 <computeroutput>swfobject.js</computeroutput> must also be included.
4342 Using the SWFObject library allows RDPWeb flash content to be embedded in
4343 a Web page using dynamic HTML. The HTML must include a "placeholder",
4344 which consists of 2 <computeroutput>div</computeroutput> elements.</para>
4345 </sect2>
4346 </sect1>
4347
4348 <sect1>
4349 <title>RDPWeb change log</title>
4350
4351 <sect2>
4352 <title>Version 1.2.28</title>
4353
4354 <itemizedlist>
4355 <listitem>
4356 <para><computeroutput>keyboardLayout</computeroutput>,
4357 <computeroutput>keyboardLayouts</computeroutput>,
4358 <computeroutput>UUID</computeroutput> properties.</para>
4359 </listitem>
4360
4361 <listitem>
4362 <para>Support for German keyboard layout on the client.</para>
4363 </listitem>
4364
4365 <listitem>
4366 <para>Rebranding to Oracle.</para>
4367 </listitem>
4368 </itemizedlist>
4369 </sect2>
4370
4371 <sect2>
4372 <title>Version 1.1.26</title>
4373
4374 <itemizedlist>
4375 <listitem>
4376 <para><computeroutput>webclient.js</computeroutput> is a part of
4377 the distribution package.</para>
4378 </listitem>
4379
4380 <listitem>
4381 <para><computeroutput>lastError</computeroutput> property.</para>
4382 </listitem>
4383
4384 <listitem>
4385 <para><computeroutput>keyboardSendScancodes</computeroutput> and
4386 <computeroutput>keyboardSendCAD</computeroutput> methods.</para>
4387 </listitem>
4388 </itemizedlist>
4389 </sect2>
4390
4391 <sect2>
4392 <title>Version 1.0.24</title>
4393
4394 <itemizedlist>
4395 <listitem>
4396 <para>Initial release.</para>
4397 </listitem>
4398 </itemizedlist>
4399 </sect2>
4400 </sect1>
4401 </chapter>
4402
4403 <chapter id="dnd">
4404 <title>Drag and Drop</title>
4405
4406 <para>As of VirtualBox 4.2 it's possible to transfer files from the host to
4407 Linux, Solaris, and macOS guests by dragging files, directories, or text
4408 from the host into the guest's screen. This is called <emphasis>drag and drop
4409 (DnD)</emphasis>.</para>
4410
4411 <para>VirtualBox 5.0 added support for Windows guests as well as the ability
4412 to transfer data in the opposite direction, that is, from the guest to the
4413 host.</para>
4414
4415 <note><para>Currently only the VirtualBox Manager front-end supports drag and
4416 drop.</para></note>
4417
4418 <para>This chapter will show how to use the required interfaces provided
4419 by VirtualBox for adding drag and drop functionality to third-party
4420 front-ends.</para>
4421
4422 <sect1>
4423 <title>Basic concepts</title>
4424
4425 <para>In order to use the interfaces provided by VirtualBox, some basic
4426 concepts need to be understood first: a drag and drop operation logically
4427 contains both a <emphasis>source</emphasis> and a
4428 <emphasis>target</emphasis>:</para>
4429
4430 <para>The <emphasis>source</emphasis> provides the data, i.e., it is the
4431 origin of data. This data can be stored within the source directly or it can
4432 be retrieved on-demand by the source itself.</para>
4433
4434 <para>The <emphasis>target</emphasis> on the other hand provides a visual
4435 representation to the source where the user can drop the data the source
4436 offers. This representation can be a window (or just a certain part of
4437 it), for example.</para>
4438
4439 <para>The source and the target have abstract interfaces called
4440 <link linkend="IDnDSource">IDnDSource</link> and
4441 <link linkend="IDnDTarget">IDnDTarget</link>. VirtualBox also
4442 provides implementations of both interfaces, called
4443 <link linkend="IGuestDnDSource">IGuestDnDSource</link> and
4444 <link linkend="IGuestDnDTarget">IGuestDnDTarget</link>. Both
4445 implementations are used in the VirtualBox Manager front-end.</para>
4446 </sect1>
4447
4448 <sect1>
4449 <title>Supported formats</title>
4450
4451 <para>As the target needs to perform specific actions depending on the
4452 data the source provided, the target first needs to know what type of
4453 data it is actually going to retrieve. It might be that the source offers
4454 data the target cannot (or intentionally does not want to)
4455 support.</para>
4456
4457 <para>VirtualBox describes the data types using
4458 <emphasis>MIME types</emphasis> -- which were originally defined in
4459 <ulink url="https://tools.ietf.org/html/rfc2046">RFC 2046</ulink> and
4460 are also called <emphasis>Content-types</emphasis> or
4461 <emphasis>media types</emphasis>.
4462 <link linkend="IGuestDnDSource">IGuestDnDSource</link> and
4463 <link linkend="IGuestDnDTarget">IGuestDnDTarget</link> support
4464 the following MIME types by default:<itemizedlist>
4465 <listitem>
4466 <para><emphasis role="bold">text/uri-list</emphasis> - A list of
4467 URIs (Uniform Resource Identifier, see
4468 <ulink url="https://tools.ietf.org/html/rfc3986">RFC 3986</ulink>)
4469 pointing to the file and/or directory paths already transferred
4470 from the source to the target.</para>
4471 </listitem>
4472 <listitem>
4473 <para><emphasis role="bold">text/plain;charset=utf-8</emphasis> and
4474 <emphasis role="bold">UTF8_STRING</emphasis> - text in UTF-8
4475 format.</para>
4476 </listitem>
4477 <listitem>
4478 <para><emphasis role="bold">text/plain, TEXT</emphasis>
4479 and <emphasis role="bold">STRING</emphasis> - plain ASCII text,
4480 depending on the source's active ANSI page (if any).</para>
4481 </listitem>
4482 </itemizedlist>
4483 </para>
4484
4485 <para>If, for whatever reason, a certain default format should not be
4486 supported or a new format should be registered,
4487 <link linkend="IDnDSource">IDnDSource</link> and
4488 <link linkend="IDnDTarget">IDnDTarget</link> have methods derived from
4489 <link linkend="IDnDBase">IDnDBase</link> which provide adding,
4490 removing and enumerating specific formats.
4491 <note><para>Registering new or removing default formats on the guest side
4492 is not currently implemented.</para></note></para>
4493 </sect1>
4494
4495 </chapter>
4496
4497 <chapter id="vbox-auth">
4498 <title>VirtualBox external authentication modules</title>
4499
4500 <para>VirtualBox supports arbitrary external modules to perform
4501 authentication. External authentication modules are used for remote
4502 desktop access to a VM when the VRDE authentication type is set to
4503 "external". VRDE authentication will then use the authentication module
4504 which was specified with
4505 <computeroutput>VBoxManage setproperty vrdeauthlibrary</computeroutput>.
4506 The web service will use the external authentication module specified with
4507 <computeroutput>VBoxManage setproperty websrvauthlibrary</computeroutput>.
4508 </para>
4509
4510 <para>This library will be loaded by the VM or web service process on
4511 demand, i.e. when the first remote desktop connection is made by a client
4512 or when a client that wants to use the web service logs on.</para>
4513
4514 <para>External authentication is the most flexible authentication type
4515 since the external handler can choose to both grant access to everyone
4516 (like the "null" authentication method) as well as delegate the request to
4517 the guest authentication component. When delegating the request to the guest
4518 component the external handler will still be called afterwards with the
4519 option to override the result.</para>
4520
4521 <para>An authentication library is required to implement exactly one entry
4522 point:</para>
4523
4524 <screen>#include "VBoxAuth.h"
4525
4526/**
4527 * Authentication library entry point.
4528 *
4529 * Parameters:
4530 *
4531 * szCaller The name of the component which calls the library (UTF8).
4532 * pUuid Pointer to the UUID of the accessed virtual machine. Can be NULL.
4533 * guestJudgement Result of the guest authentication.
4534 * szUser User name passed in by the client (UTF8).
4535 * szPassword Password passed in by the client (UTF8).
4536 * szDomain Domain passed in by the client (UTF8).
4537 * fLogon Boolean flag. Indicates whether the entry point is called
4538 * for a client logon or the client disconnect.
4539 * clientId Server side unique identifier of the client.
4540 *
4541 * Return code:
4542 *
4543 * AuthResultAccessDenied Client access has been denied.
4544 * AuthResultAccessGranted Client has the right to use the
4545 * virtual machine.
4546 * AuthResultDelegateToGuest Guest operating system must
4547 * authenticate the client and the
4548 * library must be called again with
4549 * the result of the guest
4550 * authentication.
4551 *
4552 * Note: When 'fLogon' is 0, only pszCaller, pUuid and clientId are valid and the return
4553 * code is ignored.
4554 */
4555AuthResult AUTHCALL AuthEntry(
4556 const char *szCaller,
4557 PAUTHUUID pUuid,
4558 AuthGuestJudgement guestJudgement,
4559 const char *szUser,
4560 const char *szPassword
4561 const char *szDomain
4562 int fLogon,
4563 unsigned clientId)
4564{
4565 /* Process request against your authentication source of choice. */
4566 // if (authSucceeded(...))
4567 // return AuthResultAccessGranted;
4568 return AuthResultAccessDenied;
4569}</screen>
4570
4571 <para>A note regarding the UUID implementation of the
4572 <computeroutput>pUuid</computeroutput> argument: VirtualBox uses a
4573 consistent binary representation of UUIDs on all platforms. For this
4574 reason the integer fields comprising the UUID are stored as little endian
4575 values. If you want to pass such UUIDs to code which assumes that
4576 integer fields are big endian (often also called network byte order), you
4577 need to adjust the contents of the UUID to achieve the same string
4578 representation. The required changes are:<itemizedlist>
4579 <listitem>
4580 <para>reverse the order of bytes 0, 1, 2 and 3</para>
4581 </listitem>
4582
4583 <listitem>
4584 <para>reverse the order of bytes 4 and 5</para>
4585 </listitem>
4586
4587 <listitem>
4588 <para>reverse the order of bytes 6 and 7.</para>
4589 </listitem>
4590 </itemizedlist>Using this conversion you will get identical results when
4591 converting the binary UUID to the string representation.</para>
4592
4593 <para>The <computeroutput>guestJudgement</computeroutput> argument
4594 contains information about the guest authentication status. For the first
4595 call, it is always set to
4596 <computeroutput>AuthGuestNotAsked</computeroutput>. If the
4597 <computeroutput>AuthEntry</computeroutput> function returns
4598 <computeroutput>AuthResultDelegateToGuest</computeroutput>, a guest
4599 authentication will be attempted and another call to the
4600 <computeroutput>AuthEntry</computeroutput> is made with its result. The
4601 guest authentication can return either granted, denied, or no judgement
4602 (the guest component chose for whatever reason to not make a decision).
4603 In case there is a problem with the guest authentication module (e.g. the
4604 Guest Additions are not installed or not running or the guest did not
4605 respond within a timeout), the "not reacted" status will be returned.</para>
4606 </chapter>
4607
4608 <chapter id="javaapi">
4609 <title>Using the Java API</title>
4610
4611 <sect1>
4612 <title>Introduction</title>
4613
4614 <para>VirtualBox can be controlled by a Java API, both locally using
4615 COM/XPCOM and remotely using SOAP. As with the Python bindings,
4616 a generic glue layer tries to hide all platform differences, allowing
4617 for source and binary compatibility on different platforms.</para>
4618 </sect1>
4619
4620 <sect1>
4621 <title>Requirements</title>
4622
4623 <para>To use the Java bindings, there are certain requirements depending
4624 on the platform. First of all, you need JDK 1.5 (Java 5) or later. Also
4625 please make sure that the version of the VirtualBox API .jar file
4626 exactly matches the version of VirtualBox in use. To avoid confusion,
4627 the VirtualBox API provides versioning in the Java package name, e.g.
4628 the package is named <computeroutput>org.virtualbox_3_2</computeroutput>
4629 for VirtualBox version 3.2. <itemizedlist>
4630 <listitem>
4631 <para><emphasis role="bold">XPCOM</emphasis> - for all platforms
4632 except Microsoft Windows. A Java bridge based on JavaXPCOM is shipped
4633 with VirtualBox. The classpath must contain
4634 <computeroutput>vboxjxpcom.jar</computeroutput> and the
4635 <computeroutput>vbox.home</computeroutput> property must be set to the
4636 location where the VirtualBox binaries are. Please make sure that
4637 the JVM bitness matches the bitness of VirtualBox in use as the XPCOM
4638 bridge relies on native libraries.</para>
4639
4640 <para>Start your application like this: <programlisting>
4641 java -cp vboxjxpcom.jar -Dvbox.home=/opt/virtualbox MyProgram
4642 </programlisting></para>
4643 </listitem>
4644
4645 <listitem>
4646 <para><emphasis role="bold">COM</emphasis> - for Microsoft
4647 Windows. We rely on <computeroutput>Jacob</computeroutput> - a
4648 generic Java to COM bridge - which has to be installed separately.
4649 See <ulink
4650 url="http://sourceforge.net/projects/jacob-project/">http://sourceforge.net/projects/jacob-project/</ulink>
4651 for installation instructions. Also, the VirtualBox provided
4652 <computeroutput>vboxjmscom.jar</computeroutput> file must be in the
4653 class path.</para>
4654
4655 <para>Start your application like this:
4656 <programlisting>java -cp vboxjmscom.jar;c:\jacob\jacob.jar -Djava.library.path=c:\jacob MyProgram</programlisting></para>
4657 </listitem>
4658
4659 <listitem>
4660 <para><emphasis role="bold">SOAP</emphasis> - all platforms. Java
4661 6 is required as it comes with built-in support for SOAP via the
4662 JAX-WS library. Also, the VirtualBox provided
4663 <computeroutput>vbojws.jar</computeroutput> must be in the class
4664 path. In the SOAP case it's possible to create several
4665 VirtualBoxManager instances to communicate with multiple
4666 VirtualBox hosts.</para>
4667
4668 <para>Start your application like this: <programlisting>
4669 java -cp vboxjws.jar MyProgram
4670 </programlisting></para>
4671 </listitem>
4672 </itemizedlist></para>
4673
4674 <para>Exception handling is also generalized by the generic glue layer,
4675 so that all methods can throw
4676 <computeroutput>VBoxException</computeroutput> containing a human-readable
4677 text message (see <computeroutput>getMessage()</computeroutput> method)
4678 along with the wrapped original exception (see
4679 <computeroutput>getWrapped()</computeroutput> method).</para>
4680 </sect1>
4681
4682 <sect1>
4683 <title>Example</title>
4684
4685 <para>This example shows a simple use case of the Java API. Differences
4686 for SOAP vs. local execution are minimal and limited to the connection
4687 setup phase (see <computeroutput>ws</computeroutput> variable). In the
4688 SOAP case it's possible to create several VirtualBoxManager instances to
4689 communicate with multiple VirtualBox hosts. <programlisting>
4690 import org.virtualbox_4_3.*;
4691 ....
4692 VirtualBoxManager mgr = VirtualBoxManager.createInstance(null);
4693 boolean ws = false; // or true, if we need the SOAP version
4694 if (ws)
4695 {
4696 String url = "http://myhost:18034";
4697 String user = "test";
4698 String passwd = "test";
4699 mgr.connect(url, user, passwd);
4700 }
4701 IVirtualBox vbox = mgr.getVBox();
4702 System.out.println("VirtualBox version: " + vbox.getVersion() + "\n");
4703 // get first VM name
4704 String m = vbox.getMachines().get(0).getName();
4705 System.out.println("\nAttempting to start VM '" + m + "'");
4706 // start it
4707 mgr.startVm(m, null, 7000);
4708
4709 if (ws)
4710 mgr.disconnect();
4711
4712 mgr.cleanup();
4713 </programlisting> For a more complete example, see
4714 <computeroutput>TestVBox.java</computeroutput>, shipped with the
4715 SDK. It contains exception handling and error printing code which
4716 is important for reliable larger scale projects.</para>
4717
4718 <para>It is good practice in long-running API clients to process the
4719 system events every now and then in the main thread (this does not work
4720 in other threads). As a rule of thumb it makes sense to process them
4721 every few 100msec to every few seconds). This is done by
4722 calling<programlisting>
4723 mgr.waitForEvents(0);
4724 </programlisting>
4725 This helps prevent a large number of system events from accumulating which
4726 can need a significant amount of memory, and as they also play a role in
4727 object cleanup it helps freeing additional memory in a timely manner
4728 which is used by the API implementation itself. Java's garbage collection
4729 approach already needs more memory due to the delayed freeing of memory
4730 used by no longer accessible objects and not processing the system
4731 events exacerbates the memory usage. The
4732 <computeroutput>TestVBox.java</computeroutput> example code sprinkles
4733 such lines over the code to achieve the desired effect. In multi-threaded
4734 applications it can be called from the main thread periodically.
4735 Sometimes it's possible to use the non-zero timeout variant of the
4736 method, which then waits the specified number of milliseconds for
4737 events, processing them immediately as they arrive. It achieves better
4738 runtime behavior than separate sleeping/processing.</para>
4739 </sect1>
4740 </chapter>
4741
4742 <chapter>
4743 <title>License information</title>
4744
4745 <para>The sample code files shipped with the SDK are generally licensed
4746 liberally to make it easy for anyone to use this code for their own
4747 application code.</para>
4748
4749 <para>The Java files under
4750 <computeroutput>sdk/bindings/webservice/java/jax-ws/</computeroutput> (library
4751 files for the object-oriented web service) are, by contrast, licensed
4752 under the GNU Lesser General Public License (LGPL) V2.1.</para>
4753
4754 <para>See
4755 <computeroutput>sdk/bindings/webservice/java/jax-ws/src/COPYING.LIB</computeroutput>
4756 for the full text of the LGPL 2.1.</para>
4757
4758 <para>When in doubt, please refer to the individual source code files
4759 shipped with this SDK.</para>
4760 </chapter>
4761
4762 <chapter>
4763 <title>Main API change log</title>
4764
4765 <para>Generally, VirtualBox will maintain API compatibility within a major
4766 release; a major release occurs when the first or the second of the three
4767 version components of VirtualBox change (that is, in the x.y.z scheme, a
4768 major release is one where x or y change, but not when only z
4769 changes).</para>
4770
4771 <para>In other words, updates like those from 2.0.0 to 2.0.2 will not come
4772 with API breakages.</para>
4773
4774 <para>Migration between major releases most likely will lead to API
4775 breakage, so please make sure you updated code accordingly. The OOWS Java
4776 wrappers enforce that mechanism by putting VirtualBox classes into
4777 version-specific packages such as
4778 <computeroutput>org.virtualbox_2_2</computeroutput>. This approach allows
4779 for connecting to multiple VirtualBox versions simultaneously from the
4780 same Java application.</para>
4781
4782 <para>The following sections list incompatible changes that the Main API
4783 underwent since the original release of this SDK Reference with VirtualBox
4784 2.0. A change is deemed "incompatible" only if it breaks existing client
4785 code (e.g. changes in method parameter lists, renamed or removed
4786 interfaces and similar). In other words, the list does not contain new
4787 interfaces, methods or attributes or other changes that do not affect
4788 existing client code.</para>
4789
4790 <sect1>
4791 <title>Incompatible API changes with version 7.1</title>
4792
4793 <itemizedlist>
4794
4795 <listitem><para>Review the Main API changes made for the ARM64 CPU architecture <link linkend="vboxarm">here</link>
4796 for incompatible changes to interfaces, methods, and attributes.</para>
4797 </listitem>
4798
4799 <listitem><para>The Python API bindings for Python 2.x is now marked as being deprecated and will
4800 be removed in a future version. Please upgrade your code to use Python 3.</para>
4801 </listitem>
4802
4803 <listitem><para>The Python API bindings now live in a separate <computeroutput>python</computeroutput>
4804 sub directory and also now support installing via the pip package manager
4805 (e.g. <computeroutput>pip -v install ./vboxapi</computeroutput>). This also allows installing into
4806 Python virtual environments.</para>
4807 </listitem>
4808
4809 <listitem><para>The Windows host installer now uses the sub directory <computeroutput>installer</computeroutput>
4810 instead of <computeroutput>install</computeroutput> for housing the bindings installers. This now matches
4811 the directory layout for the other platforms. Please adapt your scripts if needed.</para>
4812 </listitem>
4813
4814 <listitem><para>Guest process creation requires a new parameter for specifying the current working directory for the new
4815 guest process. This is optional and can be empty.
4816 See <link linkend="IGuestSession__processCreate">IGuestSession::processCreate</link> and
4817 <link linkend="IGuestSession__processCreateEx">IGuestSession::processCreateEx</link> for more information.</para>
4818 </listitem>
4819
4820 <listitem><para>The APIs <link linkend="IGuestSession__fsQueryInfo">IGuestSession::fsQueryInfo</link> and
4821 <link linkend="IGuestSession__fsQueryFreeSpace">IGuestSession::fsQueryFreeSpace</link> are now implemented.
4822 See <link linkend="IGuestSession__fsQueryInfo">IGuestSession::fsQueryInfo</link> and
4823 <link linkend="IGuestSession__fsQueryFreeSpace">IGuestSession::fsQueryFreeSpace</link> for more information.</para>
4824 </listitem>
4825
4826 <listitem><para>The APIs <link linkend="IGuestSession__waitFor">IGuestSession::waitFor</link> and
4827 <link linkend="IProcess__waitFor">IProcess::waitFor</link> are now marked
4828 as being deprecated. Use <link linkend="IGuestSession__waitForArray">IGuestSession::waitForArray</link>
4829 and <link linkend="IProcess__waitForArray">IProcess::waitForArray</link> instead.</para>
4830 </listitem>
4831
4832 <listitem><para>The attribute <link linkend="IGuestSession__mountPoints">IGuestSession::mountPoints</link> has been
4833 added. This requires 7.1 (or newer) Guest Additions to be installed on the guest.</para>
4834 </listitem>
4835
4836 <listitem><para>Starting a recording now has to be done via the newly introduced method
4837 <link linkend="IRecordingSettings__start">IRecordingSettings::start</link>. This method also will return
4838 a recording progress object on success, which also can be retrieved at a later time via the new attribute
4839 <link linkend="IRecordingSettings__progress">IRecordingSettings::progress</link>.</para>
4840 </listitem>
4841
4842 <listitem><para>The recording settings attribute
4843 <link linkend="IRecordingSettings__enabled">IRecordingSettings::enabled</link> does not implicitly start or stop
4844 a recording anymore, but only will indicate that recording for a VM is enabled or disabled.
4845 This attribute also will be used to determine if recording will be started automatically on VM start or restore.</para>
4846 </listitem>
4847
4848 <listitem><para>The recording settings now expose a progress object attribute via
4849 <link linkend="IRecordingSettings__progress">IRecordingSettings::progress</link>, which can be used to stop an
4850 ongoing recording, track the recording progress or getting notified of recording errors.</para>
4851 </listitem>
4852
4853 </itemizedlist>
4854 </sect1>
4855
4856 <sect1>
4857 <title>Incompatible API changes with version 7.0</title>
4858
4859 <itemizedlist>
4860
4861 <listitem><para>The machine's audio adapter has been moved into the new IAudioSettings interface, which in turn
4862 takes care of of all audio settings of a virtual machine.
4863 See <link linkend="IMachine__audioSettings">IMachine::audioSettings</link> and
4864 <link linkend="IAudioSettings">IAudioSettings</link> for more information.</para>
4865 </listitem>
4866
4867 <listitem><para>The <link linkend="IVirtualBox__openMachine">IVirtualBox::openMachine</link> call now
4868 requires an additional password parameter. If the machine is not encrypted the parameter is ignored.</para>
4869 </listitem>
4870
4871 <listitem><para>When a new VM is being created, the default audio driver will be now
4872 <link linkend="AudioDriverType__Default">AudioDriverType_Default</link>. This driver
4873 type will automatically choose the best audio driver (backend) for the host OS &VBOX_PRODUCT;
4874 currently is running on.</para>
4875 </listitem>
4876
4877 <listitem><para>The host update functionality at IHost::update has been refactored into
4878 <link linkend="IHost__updateHost">IHost::updateHost</link>, which in turn uses the new
4879 <link linkend="IHostUpdateAgent">IHostUpdateAgent</link> interface, derived from the new
4880 <link linkend="IUpdateAgent">IUpdateAgent</link> interface.</para>
4881 </listitem>
4882
4883 <listitem><para><link linkend="IGuestSession__directoryCopyFromGuest">IGuestSession::directoryCopyFromGuest()</link> and
4884 <link linkend="IGuestSession__directoryCopyToGuest">IGuestSession::directoryCopyToGuest()</link> no longer implicitly
4885 copy recursively and follow symbolic links -- for this to continue working, the newly introduced flags
4886 <link linkend="DirectoryCopyFlag__Recursive">DirectoryCopyFlag::Recursive</link> and/or
4887 <link linkend="DirectoryCopyFlag__FollowLinks">DirectoryCopyFlag::FollowLinks</link> have to be used.</para>
4888 </listitem>
4889
4890 <listitem><para>VBoxEventType_Last has been renamed to <link linkend="VBoxEventType__End">VBoxEventType_End</link>
4891 for consistency.</para></listitem>
4892
4893 </itemizedlist>
4894
4895 </sect1>
4896
4897 <sect1>
4898 <title>Incompatible API changes with version 6.1</title>
4899
4900 <itemizedlist>
4901
4902 <listitem><para>Split off the graphics adapter part of
4903 <link linkend="IMachine">IMachine</link> into
4904 <link linkend="IGraphicsAdapter">IGraphicsAdapter</link>.
4905 This moved 5 attributes.</para>
4906 </listitem>
4907
4908 </itemizedlist>
4909
4910 </sect1>
4911
4912 <sect1>
4913 <title>Incompatible API changes with version 6.0</title>
4914
4915 <itemizedlist>
4916
4917 <listitem><para>Video recording APIs were changed as follows:
4918 <itemizedlist>
4919 <listitem><para>All attributes which were living in <link linkend="IMachine">IMachine</link> before
4920 have been moved to an own, dedicated interface named <link linkend="IRecordingSettings">IRecordingSettings</link>.
4921 This new interface can be accessed via the new <link linkend="IMachine__recordingSettings">IMachine::recordingSettings</link>
4922 attribute. This should emphasize that recording is not limited to video capturing as such.</para>
4923 </listitem>
4924
4925 <listitem><para>For further flexibility all specific per-VM-screen settings have been moved to a new interface
4926 called <link linkend="IRecordingScreenSettings">IRecordingScreenSettings</link>. Such settings now exist per configured
4927 VM display and can be retrieved via the <link linkend="IRecordingSettings__screens">IRecordingSettings::screens</link>
4928 attribute or the <link linkend="IRecordingSettings__getScreenSettings">IRecordingSettings::getScreenSettings</link>
4929 method.
4930 <note><para>For now all screen settings will share the same settings, e.g. different settings on a per-screen basis
4931 is not implemented yet.</para></note>
4932 </para>
4933 </listitem>
4934
4935 <listitem><para>The event <computeroutput>IVideoCaptureChangedEvent</computeroutput> was renamed into
4936 <computeroutput>IRecordingChangedEvent</computeroutput>.</para>
4937 </listitem>
4938
4939 </itemizedlist>
4940 </para></listitem>
4941
4942 <listitem><para>Guest Control APIs were changed as follows:
4943 <itemizedlist>
4944 <listitem><para><link linkend="IGuest__createSession">IGuest::createSession()</link>,
4945 <link linkend="IGuestSession__processCreate">IGuestSession::processCreate()</link>,
4946 <link linkend="IGuestSession__processCreateEx">IGuestSession::processCreateEx()</link>,
4947 <link linkend="IGuestSession__directoryOpen">IGuestSession::directoryOpen()</link> and
4948 <link linkend="IGuestSession__fileOpen">IGuestSession::fileOpen()</link> now will
4949 return the new error code VBOX_E_MAXIMUM_REACHED if the limit for the according object
4950 group has been reached.</para>
4951 </listitem>
4952
4953 <listitem><para>The enumerations FileOpenExFlags, FsObjMoveFlags and DirectoryCopyFlags have
4954 been renamed to <link linkend="FileOpenExFlag">FileOpenExFlag</link>,
4955 <link linkend="FsObjMoveFlag">FsObjMoveFlag</link> and <link linkend="DirectoryCopyFlag">DirectoryCopyFlag</link>
4956 accordingly to match the rest of the API.</para>
4957 </listitem>
4958
4959 <listitem>
4960 <para>The following methods have been implemented:
4961 <computeroutput>IGuestSession::directoryCopyFromGuest()</computeroutput> and
4962 <computeroutput>IGuestSession::directoryCopyToGuest()</computeroutput>.
4963 </para>
4964
4965 <para>The following attributes have been implemented:
4966 <computeroutput>IGuestFsObjInfo::accessTime</computeroutput>,
4967 <computeroutput>IGuestFsObjInfo::birthTime</computeroutput>,
4968 <computeroutput>IGuestFsObjInfo::changeTime</computeroutput> and
4969 <computeroutput>IGuestFsObjInfo::modificationTime</computeroutput>.
4970 </para>
4971
4972 </listitem>
4973 </itemizedlist>
4974 </para></listitem>
4975
4976 <listitem><para>The webservice version of the <link linkend="ISharedFolder">ISharedFolder</link>
4977 interface was changed from a struct to a managed object. This causes incompatibilities on the
4978 protocol level as the shared folder attributes are not returned in the responses of
4979 <link linkend="IVirtualBox__sharedFolders">IVirtualBox::getSharedFolders</link> and
4980 <link linkend="IMachine__sharedFolders">IMachine::getSharedFolders</link> anymore. They
4981 return object UUIDs instead which need be wrapped by stub objects. The change is not visible when
4982 using the appropriate client bindings from the most recent VirtualBox SDK.
4983 </para></listitem>
4984
4985 </itemizedlist>
4986
4987 </sect1>
4988
4989 <sect1>
4990 <title>Incompatible API changes with version 5.x</title>
4991
4992 <itemizedlist>
4993 <listitem><para>ProcessCreateFlag::NoProfile has been renamed to
4994 <link linkend="ProcessCreateFlag__Profile">ProcessCreateFlag::Profile</link>,
4995 and the semantics have also been changed: ProcessCreateFlag::NoProfile
4996 explicitly <emphasis role="bold">did not</emphasis> utilize the guest user's profile data
4997 whereas <link linkend="ProcessCreateFlag__Profile">ProcessCreateFlag::Profile</link>
4998 explicitly <emphasis role="bold">does</emphasis> utilize the guest
4999 user’s profile data.</para>
5000 </listitem>
5001 </itemizedlist>
5002
5003 </sect1>
5004
5005 <sect1>
5006 <title>Incompatible API changes with version 5.1.28</title>
5007
5008 <itemizedlist>
5009 <listitem><para>The Host-Guest Communication Manager (HGCM) guest driver
5010 interfaces were renamed:
5011 <itemizedlist>
5012 <listitem><para>VbglHGCMConnect() was renamed to VbglR0HGCMConnect()
5013 </para></listitem>
5014 <listitem><para>VbglHGCMDisconnect() was renamed to VbglR0HGCMDisconnect()
5015 </para></listitem>
5016 <listitem><para>VbglHGCMCall() was renamed to VbglR0HGCMCall()
5017 </para></listitem>
5018 </itemizedlist>
5019 </para>
5020 </listitem>
5021
5022 <listitem><para>The Host-Guest Communication Manager (HGCM) guest
5023 application interface IOCTLs were renamed:
5024 <itemizedlist>
5025 <listitem><para>VBOXGUEST_IOCTL_HGCM_CONNECT was renamed to
5026 VBGL_IOCTL_HGCM_CONNECT
5027 </para></listitem>
5028 <listitem><para>VBOXGUEST_IOCTL_HGCM_DISCONNECT was renamed to
5029 VBGL_IOCTL_HGCM_DISCONNECT
5030 </para></listitem>
5031 <listitem><para>VBOXGUEST_IOCTL_HGCM_CALL was renamed to
5032 VBGL_IOCTL_HGCM_CALL
5033 </para></listitem>
5034 </itemizedlist>
5035 </para>
5036 </listitem>
5037
5038 </itemizedlist>
5039
5040 </sect1>
5041
5042
5043 <sect1>
5044 <title>Incompatible API changes with version 5.0</title>
5045
5046 <itemizedlist>
5047 <listitem>
5048 <para>The methods for saving state, adopting a saved state file,
5049 discarding a saved state, taking a snapshot, restoring
5050 a snapshot and deleting a snapshot have been moved from
5051 <computeroutput>IConsole</computeroutput> to
5052 <computeroutput>IMachine</computeroutput>. This straightens out the
5053 logical placement of methods and was necessary to resolve a
5054 long-standing issue, preventing 32-bit API clients from invoking
5055 those operations in the case where no VM is running.
5056 <itemizedlist>
5057 <listitem><para><link linkend="IMachine__saveState">IMachine::saveState()</link>
5058 replaces
5059 <computeroutput>IConsole::saveState()</computeroutput></para>
5060 </listitem>
5061 <listitem>
5062 <para><link linkend="IMachine__adoptSavedState">IMachine::adoptSavedState()</link>
5063 replaces
5064 <computeroutput>IConsole::adoptSavedState()</computeroutput></para>
5065 </listitem>
5066 <listitem>
5067 <para><link linkend="IMachine__discardSavedState">IMachine::discardSavedState()</link>
5068 replaces
5069 <computeroutput>IConsole::discardSavedState()</computeroutput></para>
5070 </listitem>
5071 <listitem>
5072 <para><link linkend="IMachine__takeSnapshot">IMachine::takeSnapshot()</link>
5073 replaces
5074 <computeroutput>IConsole::takeSnapshot()</computeroutput></para>
5075 </listitem>
5076 <listitem>
5077 <para><link linkend="IMachine__deleteSnapshot">IMachine::deleteSnapshot()</link>
5078 replaces
5079 <computeroutput>IConsole::deleteSnapshot()</computeroutput></para>
5080 </listitem>
5081 <listitem>
5082 <para><link linkend="IMachine__deleteSnapshotAndAllChildren">IMachine::deleteSnapshotAndAllChildren()</link>
5083 replaces
5084 <computeroutput>IConsole::deleteSnapshotAndAllChildren()</computeroutput></para>
5085 </listitem>
5086 <listitem>
5087 <para><link linkend="IMachine__deleteSnapshotRange">IMachine::deleteSnapshotRange()</link>
5088 replaces
5089 <computeroutput>IConsole::deleteSnapshotRange()</computeroutput></para>
5090 </listitem>
5091 <listitem>
5092 <para><link linkend="IMachine__restoreSnapshot">IMachine::restoreSnapshot()</link>
5093 replaces
5094 <computeroutput>IConsole::restoreSnapshot()</computeroutput></para>
5095 </listitem>
5096 </itemizedlist>
5097 Small adjustments to the parameter lists have been made to reduce
5098 the number of API calls when taking online snapshots (no longer
5099 needs explicit pausing), and taking a snapshot also returns now
5100 the snapshot id (useful for finding the right snapshot if there
5101 are non-unique snapshot names).</para>
5102 </listitem>
5103
5104 <listitem>
5105 <para>Two new machine states have been introduced to allow proper
5106 distinction between saving state and taking a snapshot.
5107 <link linkend="MachineState__Saving">MachineState::Saving</link>
5108 now is used exclusively while the VM's state is being saved, without
5109 any overlaps with snapshot functionality. The new state
5110 <link linkend="MachineState__Snapshotting">MachineState::Snapshotting</link>
5111 is used when an offline snapshot is taken and likewise the new state
5112 <link linkend="MachineState__OnlineSnapshotting">MachineState::OnlineSnapshotting</link>
5113 is used when an online snapshot is taken.</para>
5114 </listitem>
5115
5116 <listitem>
5117 <para>A new event has been introduced, which signals when a snapshot
5118 has been restored:
5119 <link linkend="ISnapshotRestoredEvent">ISnapshotRestoredEvent</link>.
5120 Previously the event
5121 <link linkend="ISnapshotDeletedEvent">ISnapshotDeletedEvent</link>
5122 was signalled, which isn't logical (but could be distinguished from
5123 actual deletion by the fact that the snapshot was still
5124 there).</para>
5125 </listitem>
5126
5127 <listitem>
5128 <para>The method
5129 <link linkend="IVirtualBox__createMedium">IVirtualBox::createMedium()</link>
5130 replaces
5131 <computeroutput>VirtualBox::createHardDisk()</computeroutput>.
5132 Adjusting existing code needs adding two parameters with
5133 value <computeroutput>AccessMode_ReadWrite</computeroutput>
5134 and <computeroutput>DeviceType_HardDisk</computeroutput>
5135 respectively. The new method supports creating floppy and
5136 DVD images, and (less obviously) further API functionality
5137 such as cloning floppy images.</para>
5138 </listitem>
5139
5140 <listitem>
5141 <para>The method
5142 <link linkend="IMachine__getStorageControllerByInstance">IMachine::getStorageControllerByInstance()</link>
5143 now has an additional parameter (first parameter), for specifying the
5144 storage bus which the storage controller must be using. The method
5145 was not useful before, as the instance numbers are only unique for a
5146 specfic storage bus.</para>
5147 </listitem>
5148
5149 <listitem>
5150 <para>The attribute
5151 <computeroutput>IMachine::sessionType</computeroutput> has been
5152 renamed to
5153 <link linkend="IMachine__sessionName">IMachine::sessionName()</link>.
5154 This cleans up the confusing terminology (as the session type is
5155 something different).</para>
5156 </listitem>
5157
5158 <listitem>
5159 <para>The attribute
5160 <computeroutput>IMachine::guestPropertyNotificationPatterns</computeroutput>
5161 has been removed. In practice it was not usable because it is too
5162 global and didn't distinguish between API clients.</para>
5163 </listitem>
5164
5165 <listitem><para>Drag and drop APIs were changed as follows:<itemizedlist>
5166
5167 <listitem>
5168 <para>Methods for providing host to guest drag and drop
5169 functionality, such as
5170 <computeroutput>IGuest::dragHGEnter</computeroutput>,
5171 <computeroutput>IGuest::dragHGMove()</computeroutput>,
5172 <computeroutput>IGuest::dragHGLeave()</computeroutput>,
5173 <computeroutput>IGuest::dragHGDrop()</computeroutput> and
5174 <computeroutput>IGuest::dragHGPutData()</computeroutput>,
5175 have been moved to an abstract base class called
5176 <link linkend="IDnDTarget">IDnDTarget</link>.
5177 VirtualBox implements this base class in the
5178 <link linkend="IGuestDnDTarget">IGuestDnDTarget</link>
5179 interface. The implementation can be used by using the
5180 <link linkend="IGuest__dnDTarget">IGuest::dnDTarget()</link>
5181 method.</para>
5182 <para>Methods for providing guest to host drag and drop
5183 functionality, such as
5184 <computeroutput>IGuest::dragGHPending()</computeroutput>,
5185 <computeroutput>IGuest::dragGHDropped()</computeroutput> and
5186 <computeroutput>IGuest::dragGHGetData()</computeroutput>,
5187 have been moved to an abstract base class called
5188 <link linkend="IDnDSource">IDnDSource</link>.
5189 VirtualBox implements this base class in the
5190 <link linkend="IGuestDnDSource">IGuestDnDSource</link>
5191 interface. The implementation can be used by using the
5192 <link linkend="IGuest__dnDSource">IGuest::dnDSource()</link>
5193 method.</para>
5194 </listitem>
5195
5196 <listitem>
5197 <para>The <computeroutput>DragAndDropAction</computeroutput>
5198 enumeration has been renamed to
5199 <link linkend="DnDAction">DnDAction</link>.</para>
5200 </listitem>
5201
5202 <listitem>
5203 <para>The <computeroutput>DragAndDropMode</computeroutput>
5204 enumeration has been renamed to
5205 <link linkend="DnDMode">DnDMode</link>.</para>
5206 </listitem>
5207
5208 <listitem>
5209 <para>The attribute
5210 <computeroutput>IMachine::dragAndDropMode</computeroutput>
5211 has been renamed to
5212 <link linkend="IMachine__dnDMode">IMachine::dnDMode()</link>.</para>
5213 </listitem>
5214
5215 <listitem>
5216 <para>The event
5217 <computeroutput>IDragAndDropModeChangedEvent</computeroutput>
5218 has been renamed to
5219 <link linkend="IDnDModeChangedEvent">IDnDModeChangedEvent</link>.</para>
5220 </listitem>
5221
5222 </itemizedlist></para>
5223 </listitem>
5224
5225 <listitem><para>IDisplay and IFramebuffer interfaces were changed to
5226 allow IFramebuffer object to reside in a separate front-end
5227 process:<itemizedlist>
5228
5229 <listitem><para>
5230 IDisplay::ResizeCompleted() has been removed, because the
5231 IFramebuffer object does not provide the screen memory anymore.
5232 </para></listitem>
5233
5234 <listitem><para>
5235 IDisplay::SetFramebuffer() has been replaced with
5236 IDisplay::AttachFramebuffer() and IDisplay::DetachFramebuffer().
5237 </para></listitem>
5238
5239 <listitem><para>
5240 IDisplay::GetFramebuffer() has been replaced with
5241 IDisplay::QueryFramebuffer().
5242 </para></listitem>
5243
5244 <listitem><para>
5245 IDisplay::GetScreenResolution() has a new output parameter
5246 <computeroutput>guestMonitorStatus</computeroutput>
5247 which tells whether the monitor is enabled in the guest.
5248 </para></listitem>
5249
5250 <listitem><para>
5251 IDisplay::TakeScreenShot() and IDisplay::TakeScreenShotToArray()
5252 have a new parameter
5253 <computeroutput>bitmapFormat</computeroutput>. As a consequence of
5254 this, IDisplay::TakeScreenShotPNGToArray() has been removed.
5255 </para></listitem>
5256
5257 <listitem><para>
5258 IFramebuffer::RequestResize() has been replaced with
5259 IFramebuffer::NotifyChange().
5260 </para></listitem>
5261
5262 <listitem><para>
5263 IFramebuffer::NotifyUpdateImage() added to support IFramebuffer
5264 objects in a different process.
5265 </para></listitem>
5266
5267 <listitem><para>
5268 IFramebuffer::Lock(), IFramebuffer::Unlock(),
5269 IFramebuffer::Address(), IFramebuffer::UsesGuestVRAM() have been
5270 removed because the IFramebuffer object does not provide the screen
5271 memory anymore.
5272 </para></listitem>
5273
5274 </itemizedlist></para>
5275 </listitem>
5276
5277 <listitem><para>IGuestSession, IGuestFile and IGuestProcess interfaces
5278 were changed as follows:
5279 <itemizedlist>
5280 <listitem>
5281 <para>Replaced IGuestSession::directoryQueryInfo and
5282 IGuestSession::fileQueryInfo with a new
5283 <link linkend="IGuestSession__fsObjQueryInfo">IGuestSession::fsObjQueryInfo</link>
5284 method that works on any type of file system object.</para>
5285 </listitem>
5286 <listitem>
5287 <para>Replaced IGuestSession::fileRemove,
5288 IGuestSession::symlinkRemoveDirectory and
5289 IGuestSession::symlinkRemoveFile with a new
5290 <link linkend="IGuestSession__fsObjRemove">IGuestSession::fsObjRemove</link>
5291 method that works on any type of file system object except
5292 directories. (fileRemove also worked on any type of object
5293 too, though that was not the intent of the method.)</para>
5294 </listitem>
5295 <listitem>
5296 <para>Replaced IGuestSession::directoryRename and
5297 IGuestSession::directoryRename with a new
5298 <link linkend="IGuestSession__fsObjRename">IGuestSession::fsObjRename</link>
5299 method that works on any type of file system object.
5300 (directoryRename and fileRename may already have worked for
5301 any kind of object, but that was never the intent of the
5302 methods.)</para>
5303 </listitem>
5304 <listitem>
5305 <para>Replaced the unimplemented IGuestSession::directorySetACL
5306 and IGuestSession::fileSetACL with a new
5307 <link linkend="IGuestSession__fsObjSetACL">IGuestSession::fsObjSetACL</link>
5308 method that works on all type of file system object. Also
5309 added a UNIX-style mode parameter as an alternative to the
5310 ACL.</para>
5311 </listitem>
5312 <listitem>
5313 <para>Replaced IGuestSession::fileRemove,
5314 IGuestSession::symlinkRemoveDirectory and
5315 IGuestSession::symlinkRemoveFile with a new
5316 <link linkend="IGuestSession__fsObjRemove">IGuestSession::fsObjRemove</link>
5317 method that works on any type of file system object except
5318 directories (fileRemove also worked on any type of object,
5319 though that was not the intent of the method.)</para>
5320 </listitem>
5321 <listitem>
5322 <para>Renamed IGuestSession::copyTo to
5323 <link linkend="IGuestSession__fileCopyToGuest">IGuestSession::fileCopyToGuest</link>.</para>
5324 </listitem>
5325 <listitem>
5326 <para>Renamed IGuestSession::copyFrom to
5327 <link linkend="IGuestSession__fileCopyFromGuest">IGuestSession::fileCopyFromGuest</link>.</para>
5328 </listitem>
5329 <listitem>
5330 <para>Renamed the CopyFileFlag enum to
5331 <link linkend="FileCopyFlag">FileCopyFlag</link>.</para>
5332 </listitem>
5333 <listitem>
5334 <para>Renamed the IGuestSession::environment attribute to
5335 <link linkend="IGuestSession__environmentChanges">IGuestSession::environmentChanges</link>
5336 to better reflect what it does.</para>
5337 </listitem>
5338 <listitem>
5339 <para>Changed the
5340 <link linkend="IProcess__environment">IGuestProcess::environment</link>
5341 to a stub returning E_NOTIMPL since it wasn't doing what was
5342 advertised (returned changes, not the actual environment).</para>
5343 </listitem>
5344 <listitem>
5345 <para>Renamed IGuestSession::environmentSet to
5346 <link linkend="IGuestSession__environmentScheduleSet">IGuestSession::environmentScheduleSet</link>
5347 to better reflect what it does.</para>
5348 </listitem>
5349 <listitem>
5350 <para>Renamed IGuestSession::environmentUnset to
5351 <link linkend="IGuestSession__environmentScheduleUnset">IGuestSession::environmentScheduleUnset</link>
5352 to better reflect what it does.</para>
5353 </listitem>
5354 <listitem>
5355 <para>Removed IGuestSession::environmentGet it was only getting
5356 changes while giving the impression it was actual environment
5357 variables, and it did not represent scheduled unset
5358 operations.</para>
5359 </listitem>
5360 <listitem>
5361 <para>Removed IGuestSession::environmentClear as it duplicates
5362 assigning an empty array to the
5363 <link linkend="IGuestSession__environmentChanges">IGuestSession::environmentChanges</link>
5364 (formerly known as IGuestSession::environment).</para>
5365 </listitem>
5366 <listitem>
5367 <para>Changed the
5368 <link linkend="IGuestSession__processCreate">IGuestSession::processCreate</link>
5369 and
5370 <link linkend="IGuestSession__processCreateEx">IGuestSession::processCreateEx</link>
5371 methods to accept arguments starting with argument zero (argv[0])
5372 instead of argument one (argv[1]). (Not yet implemented on the
5373 guest additions side, so argv[0] will probably be ignored for a
5374 short while.)</para>
5375 </listitem>
5376
5377 <listitem>
5378 <para>Added a followSymlink parameter to the following methods:
5379 <itemizedlist>
5380 <listitem><para><link linkend="IGuestSession__directoryExists">IGuestSession::directoryExists</link></para></listitem>
5381 <listitem><para><link linkend="IGuestSession__fileExists">IGuestSession::fileExists</link></para></listitem>
5382 <listitem><para><link linkend="IGuestSession__fileQuerySize">IGuestSession::fileQuerySize</link></para></listitem>
5383 </itemizedlist></para>
5384 </listitem>
5385 <listitem>
5386 <para>The parameters to the
5387 <link linkend="IGuestSession__fileOpen">IGuestSession::fileOpen</link>
5388 and
5389 <link linkend="IGuestSession__fileOpenEx">IGuestSession::fileOpenEx</link>
5390 methods were altered:<itemizedlist>
5391 <listitem><para>The openMode string parameter was replaced by
5392 the enum
5393 <link linkend="FileAccessMode">FileAccessMode</link>
5394 and renamed to accessMode.</para></listitem>
5395 <listitem><para>The disposition string parameter was replaced
5396 by the enum
5397 <link linkend="FileOpenAction">FileOpenAction</link>
5398 and renamed to openAction.</para></listitem>
5399 <listitem><para>The unimplemented sharingMode string parameter
5400 was replaced by the enum
5401 <link linkend="FileSharingMode">FileSharingMode</link>
5402 (fileOpenEx only).</para></listitem>
5403 <listitem><para>Added a flags parameter taking a list of
5404 <link linkend="FileOpenExFlag">FileOpenExFlag</link> values
5405 (fileOpenEx only).</para></listitem>
5406 <listitem><para>Removed the offset parameter (fileOpenEx
5407 only).</para></listitem>
5408 </itemizedlist></para>
5409 </listitem>
5410
5411 <listitem>
5412 <para><link linkend="IFile__seek">IGuestFile::seek</link> now
5413 returns the new offset.</para>
5414 </listitem>
5415 <listitem>
5416 <para>Renamed the FileSeekType enum used by
5417 <link linkend="IFile__seek">IGuestFile::seek</link>
5418 to <link linkend="FileSeekOrigin">FileSeekOrigin</link> and
5419 added the missing End value and renaming the Set to
5420 Begin.</para>
5421 </listitem>
5422 <listitem>
5423 <para>Extended the unimplemented
5424 <link linkend="IFile__setACL">IGuestFile::setACL</link>
5425 method with a UNIX-style mode parameter as an alternative to
5426 the ACL.</para>
5427 </listitem>
5428 <listitem>
5429 <para>Renamed the IFile::openMode attribute to
5430 <link linkend="IFile__accessMode">IFile::accessMode</link>
5431 and change the type from string to
5432 <link linkend="FileAccessMode">FileAccessMode</link> to reflect
5433 the changes to the fileOpen methods.</para>
5434 </listitem>
5435 <listitem>
5436 <para>Renamed the IGuestFile::disposition attribute to
5437 <link linkend="IFile__openAction">IFile::openAction</link> and
5438 change the type from string to
5439 <link linkend="FileOpenAction">FileOpenAction</link> to reflect
5440 the changes to the fileOpen methods.</para>
5441 </listitem>
5442
5443 <!-- Non-incompatible things worth mentioning (stubbed methods/attrs aren't worth it). -->
5444 <listitem>
5445 <para>Added
5446 <link linkend="IGuestSession__pathStyle">IGuestSession::pathStyle</link>
5447 attribute.</para>
5448 </listitem>
5449 <listitem>
5450 <para>Added
5451 <link linkend="IGuestSession__fsObjExists">IGuestSession::fsObjExists</link>
5452 attribute.</para>
5453 </listitem>
5454
5455 </itemizedlist>
5456 </para>
5457 </listitem>
5458
5459 <listitem><para>
5460 IConsole::GetDeviceActivity() returns information about multiple
5461 devices.
5462 </para></listitem>
5463
5464 <listitem><para>
5465 IMachine::ReadSavedThumbnailToArray() has a new parameter
5466 <computeroutput>bitmapFormat</computeroutput>. As a consequence of
5467 this, IMachine::ReadSavedThumbnailPNGToArray() has been removed.
5468 </para></listitem>
5469
5470 <listitem><para>
5471 IMachine::QuerySavedScreenshotPNGSize() has been renamed to
5472 IMachine::QuerySavedScreenshotInfo() which also returns
5473 an array of available screenshot formats.
5474 </para></listitem>
5475
5476 <listitem><para>
5477 IMachine::ReadSavedScreenshotPNGToArray() has been renamed to
5478 IMachine::ReadSavedScreenshotToArray() which has a new parameter
5479 <computeroutput>bitmapFormat</computeroutput>.
5480 </para></listitem>
5481
5482 <listitem><para>
5483 IMachine::QuerySavedThumbnailSize() has been removed.
5484 </para></listitem>
5485
5486 <listitem>
5487 <para>The method
5488 <link linkend="IWebsessionManager__getSessionObject">IWebsessionManager::getSessionObject()</link>
5489 now returns a new <link linkend="ISession">ISession</link> instance
5490 for every invocation. This puts the behavior in line with other
5491 binding styles, which never forced the equivalent of establishing
5492 another connection and logging in again to get another
5493 instance.</para>
5494 </listitem>
5495 </itemizedlist>
5496 </sect1>
5497
5498 <sect1>
5499 <title>Incompatible API changes with version 4.3</title>
5500
5501 <itemizedlist>
5502 <listitem>
5503 <para>The explicit medium locking methods
5504 <link linkend="IMedium__lockRead">IMedium::lockRead()</link>
5505 and <link linkend="IMedium__lockWrite">IMedium::lockWrite()</link>
5506 have been redesigned. They return a lock token object reference
5507 now, and calling the
5508 <link linkend="IToken__abandon">IToken::abandon()</link> method (or
5509 letting the reference count to this object drop to 0) will unlock
5510 it. This eliminates the rather common problem that an API client
5511 crash left behind locks, and also improves the safety (API clients
5512 can't release locks they didn't obtain).</para>
5513 </listitem>
5514
5515 <listitem>
5516 <para>The parameter list of
5517 <link linkend="IAppliance__write">IAppliance::write()</link>
5518 has been changed slightly, to allow multiple flags to be
5519 passed.</para>
5520 </listitem>
5521
5522 <listitem>
5523 <para><computeroutput>IMachine::delete</computeroutput>
5524 has been renamed to
5525 <link linkend="IMachine__deleteConfig">IMachine::deleteConfig()</link>,
5526 to improve API client binding compatibility.</para>
5527 </listitem>
5528
5529 <listitem>
5530 <para><computeroutput>IMachine::export</computeroutput>
5531 has been renamed to
5532 <link linkend="IMachine__exportTo">IMachine::exportTo()</link>,
5533 to improve API client binding compatibility.</para>
5534 </listitem>
5535
5536 <listitem>
5537 <para>For
5538 <link linkend="IMachine__launchVMProcess">IMachine::launchVMProcess()</link>
5539 the meaning of the <computeroutput>type</computeroutput> parameter
5540 has changed slightly. Empty string now means that the per-VM or
5541 global default front-end is launched. Most callers of this method
5542 should use the empty string now, unless they really want to override
5543 the default and launch a particular front-end.</para>
5544 </listitem>
5545
5546 <listitem>
5547 <para>Medium management APIs were changed as follows:<itemizedlist>
5548
5549 <listitem>
5550 <para>The type of attribute
5551 <link linkend="IMedium__variant">IMedium::variant()</link>
5552 changed from <computeroutput>unsigned long</computeroutput>
5553 to <computeroutput>safe-array MediumVariant</computeroutput>.
5554 It is an array of flags instead of a set of flags which were
5555 stored inside one variable.
5556 </para>
5557 </listitem>
5558
5559 <listitem>
5560 <para>The parameter list for
5561 <link linkend="IMedium__cloneTo">IMedium::cloneTo()</link>
5562 was modified. The type of parameter variant was changed from
5563 unsigned long to safe-array MediumVariant.
5564 </para>
5565 </listitem>
5566
5567 <listitem>
5568 <para>The parameter list for
5569 <link linkend="IMedium__createBaseStorage">IMedium::createBaseStorage()</link>
5570 was modified. The type of parameter variant was changed from
5571 unsigned long to safe-array MediumVariant.
5572 </para>
5573 </listitem>
5574
5575 <listitem>
5576 <para>The parameter list for
5577 <link linkend="IMedium__createDiffStorage">IMedium::createDiffStorage()</link>
5578 was modified. The type of parameter variant was changed from
5579 unsigned long to safe-array MediumVariant.
5580 </para>
5581 </listitem>
5582
5583 <listitem>
5584 <para>The parameter list for
5585 <link linkend="IMedium__cloneToBase">IMedium::cloneToBase()</link>
5586 was modified. The type of parameter variant was changed from
5587 unsigned long to safe-array MediumVariant.
5588 </para>
5589 </listitem>
5590 </itemizedlist></para>
5591 </listitem>
5592
5593 <listitem>
5594 <para>The type of attribute
5595 <link linkend="IMediumFormat__capabilities">IMediumFormat::capabilities()</link>
5596 changed from <computeroutput>unsigned long</computeroutput> to
5597 <computeroutput>safe-array MediumFormatCapabilities</computeroutput>.
5598 It is an array of flags instead of a set of flags which were stored
5599 inside one variable.
5600 </para>
5601 </listitem>
5602
5603 <listitem>
5604 <para>The attribute
5605 <link linkend="IMedium__logicalSize">IMedium::logicalSize()</link>
5606 now returns the logical size of exactly this medium object (whether
5607 it is a base or diff image). The old behavior was no longer
5608 acceptable, as each image can have a different capacity.</para>
5609 </listitem>
5610
5611 <listitem>
5612 <para>Guest control APIs - such as
5613 <link linkend="IGuest">IGuest</link>,
5614 <link linkend="IGuestSession">IGuestSession</link>,
5615 <link linkend="IGuestProcess">IGuestProcess</link> and so on - now
5616 emit own events to provide clients much finer control and the ability
5617 to write own front-ends for guest operations. The event
5618 <link linkend="IGuestSessionEvent">IGuestSessionEvent</link> acts as
5619 an abstract base class for all guest control events. Certain guest
5620 events contain a
5621 <link linkend="IVirtualBoxErrorInfo">IVirtualBoxErrorInfo</link>
5622 member to provide more information in case of an error happened on
5623 the guest side.</para>
5624 </listitem>
5625
5626 <listitem>
5627 <para>Guest control sessions on the guest started by
5628 <link linkend="IGuest__createSession">IGuest::createSession()</link>
5629 now are dedicated guest processes to provide more safety and
5630 performance for certain operations. Also, the
5631 <link linkend="IGuest__createSession">IGuest::createSession()</link>
5632 call does not wait for the guest session being created anymore due
5633 to the dedicated guest session processes just mentioned. This also
5634 will enable webservice clients to handle guest session creation
5635 more gracefully. To wait for a guest session being started, use the
5636 newly added attribute
5637 <link linkend="IGuestSession__status">IGuestSession::status()</link>
5638 to query the current guest session status.</para>
5639 </listitem>
5640
5641 <listitem>
5642 <para>The <link linkend="IGuestFile">IGuestFile</link>
5643 APIs are now implemented to provide native guest file access from
5644 the host.</para>
5645 </listitem>
5646
5647 <listitem>
5648 <para>The parameter list for
5649 <link linkend="IGuest__updateGuestAdditions">IMedium::updateGuestAdditions()</link>
5650 was modified. It now supports specifying optional command line
5651 arguments for the Guest Additions installer performing the actual
5652 update on the guest.
5653 </para>
5654 </listitem>
5655
5656 <listitem>
5657 <para>A new event
5658 <link linkend="IGuestUserStateChangedEvent">IGuestUserStateChangedEvent</link>
5659 was introduced to provide guest user status updates to the host via
5660 event listeners. To use this event there needs to be at least the 4.3
5661 Guest Additions installed on the guest. At the moment only the states
5662 "Idle" and "InUse" of the
5663 <link linkend="GuestUserState">GuestUserState</link> enumeration arei
5664 supported on Windows guests, starting at Windows 2000 SP2.</para>
5665 </listitem>
5666
5667 <listitem>
5668 <para>
5669 The attribute
5670 <link linkend="IGuestSession__protocolVersion">IGuestSession::protocolVersion</link>
5671 was added to provide a convenient way to lookup the guest session's
5672 protocol version it uses to communicate with the installed Guest
5673 Additions on the guest. Older Guest Additions will set the protocol
5674 version to 1, whereas Guest Additions 4.3 will set the protocol
5675 version to 2. This might change in the future as new features
5676 arise.</para>
5677 </listitem>
5678
5679 <listitem>
5680 <para><computeroutput>IDisplay::getScreenResolution</computeroutput>
5681 has been extended to return the display position in the guest.</para>
5682 </listitem>
5683
5684 <listitem>
5685 <para>
5686 The <link linkend="IUSBController">IUSBController</link>
5687 class is not a singleton of
5688 <link linkend="IMachine">IMachine</link> anymore but
5689 <link linkend="IMachine">IMachine</link> contains a list of USB
5690 controllers present in the VM. The USB device filter handling was
5691 moved to
5692 <link linkend="IUSBDeviceFilters">IUSBDeviceFilters</link>.
5693 </para>
5694 </listitem>
5695 </itemizedlist>
5696 </sect1>
5697
5698 <sect1>
5699 <title>Incompatible API changes with version 4.2</title>
5700
5701 <itemizedlist>
5702 <listitem>
5703 <para>Guest control APIs for executing guest processes, working with
5704 guest files or directories have been moved to the newly introduced
5705 <link linkend="IGuestSession">IGuestSession</link> interface which
5706 can be created by calling
5707 <link linkend="IGuest__createSession">IGuest::createSession()</link>.</para>
5708
5709 <para>A guest session will act as a
5710 guest user's impersonation so that the guest credentials only have to
5711 be provided when creating a new guest session. There can be up to 32
5712 guest sessions at once per VM, each session serving up to 2048 guest
5713 processes running or files opened.</para>
5714
5715 <para>Instead of working with process or directory handles before
5716 version 4.2, there now are the dedicated interfaces
5717 <link linkend="IGuestProcess">IGuestProcess</link>,
5718 <link linkend="IGuestDirectory">IGuestDirectory</link> and
5719 <link linkend="IGuestFile">IGuestFile</link>. To retrieve more
5720 information of a file system object the new interface
5721 <link linkend="IGuestFsObjInfo">IGuestFsObjInfo</link> has been
5722 introduced.</para>
5723
5724 <para>Even though the guest control API was changed it is backwards
5725 compatible so that it can be used with older installed Guest
5726 Additions. However, to use upcoming features like process termination
5727 or waiting for input / output new Guest Additions must be installed
5728 when these features got implemented.</para>
5729
5730 <para>The following limitations apply:
5731 <itemizedlist>
5732 <listitem><para>The <link linkend="IGuestFile">IGuestFile</link>
5733 interface is not fully implemented yet.</para>
5734 </listitem>
5735 <listitem><para>The symbolic link APIs
5736 <link linkend="IGuestSession__symlinkCreate">IGuestSession::symlinkCreate()</link>,
5737 <link linkend="IGuestSession__symlinkExists">IGuestSession::symlinkExists()</link>,
5738 <link linkend="IGuestSession__symlinkRead">IGuestSession::symlinkRead()</link>,
5739 IGuestSession::symlinkRemoveDirectory() and
5740 IGuestSession::symlinkRemoveFile() are not
5741 implemented yet.</para>
5742 </listitem>
5743 <listitem><para>The directory APIs
5744 <link linkend="IGuestSession__directoryRemove">IGuestSession::directoryRemove()</link>,
5745 <link linkend="IGuestSession__directoryRemoveRecursive">IGuestSession::directoryRemoveRecursive()</link>,
5746 IGuestSession::directoryRename() and
5747 IGuestSession::directorySetACL() are not
5748 implemented yet.</para>
5749 </listitem>
5750 <listitem><para>The temporary file creation API
5751 <link linkend="IGuestSession__fileCreateTemp">IGuestSession::fileCreateTemp()</link>
5752 is not implemented yet.</para>
5753 </listitem>
5754 <listitem><para>Guest process termination via
5755 <link linkend="IProcess__terminate">IProcess::terminate()</link>
5756 is not implemented yet.</para>
5757 </listitem>
5758 <listitem><para>Waiting for guest process output via
5759 <link linkend="ProcessWaitForFlag__StdOut">ProcessWaitForFlag::StdOut</link>
5760 and
5761 <link linkend="ProcessWaitForFlag__StdErr">ProcessWaitForFlag::StdErr</link>
5762 is not implemented yet.</para>
5763 <para>To wait for process output,
5764 <link linkend="IProcess__read">IProcess::read()</link> with
5765 appropriate flags still can be used to periodically check for
5766 new output data to arrive. Note that
5767 <link linkend="ProcessCreateFlag__WaitForStdOut">ProcessCreateFlag::WaitForStdOut</link>
5768 and / or
5769 <link linkend="ProcessCreateFlag__WaitForStdErr">ProcessCreateFlag::WaitForStdErr</link>
5770 need to be specified when creating a guest process via
5771 <link linkend="IGuestSession__processCreate">IGuestSession::processCreate()</link>
5772 or
5773 <link linkend="IGuestSession__processCreateEx">IGuestSession::processCreateEx()</link>.</para>
5774 </listitem>
5775 <listitem>
5776 <para>ACL (Access Control List) handling in general is not
5777 implemented yet.</para>
5778 </listitem>
5779 </itemizedlist>
5780 </para>
5781 </listitem>
5782
5783 <listitem>
5784 <para>The <link linkend="LockType">LockType</link>
5785 enumeration now has an additional value
5786 <computeroutput>VM</computeroutput> which tells
5787 <link linkend="IMachine__lockMachine">IMachine::lockMachine()</link>
5788 to create a full-blown object structure for running a VM. This was
5789 the previous behavior with <computeroutput>Write</computeroutput>,
5790 which now only creates the minimal object structure to save time and
5791 resources (at the moment the Console object is still created, but all
5792 sub-objects such as Display, Keyboard, Mouse, Guest are not.</para>
5793 </listitem>
5794
5795 <listitem>
5796 <para>Machines can be put in groups (actually an array of groups).
5797 The primary group affects the default placement of files belonging
5798 to a VM.
5799 <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
5800 and
5801 <link linkend="IVirtualBox__composeMachineFilename">IVirtualBox::composeMachineFilename()</link>
5802 have been adjusted accordingly, the former taking an array of groups
5803 as an additional parameter and the latter taking a group as an
5804 additional parameter. The create option handling has been changed for
5805 those two methods, too.</para>
5806 </listitem>
5807
5808 <listitem>
5809 <para>The method IVirtualBox::findMedium() has been removed, since
5810 it provides a subset of the functionality of
5811 <link linkend="IVirtualBox__openMedium">IVirtualBox::openMedium()</link>.</para>
5812 </listitem>
5813
5814 <listitem>
5815 <para>The use of acronyms in API enumeration, interface, attribute
5816 and method names has been made much more consistent, previously they
5817 sometimes were lowercase and sometimes mixed case. They are now
5818 consistently all caps:<table>
5819 <title>Renamed identifiers in VirtualBox 4.2</title>
5820
5821 <tgroup cols="2" style="verywide">
5822 <tbody>
5823 <row>
5824 <entry><emphasis role="bold">Old name</emphasis></entry>
5825
5826 <entry><emphasis role="bold">New name</emphasis></entry>
5827 </row>
5828 <row>
5829 <entry>PointingHidType</entry>
5830 <entry><link linkend="PointingHIDType">PointingHIDType</link></entry>
5831 </row>
5832 <row>
5833 <entry>KeyboardHidType</entry>
5834 <entry><link linkend="KeyboardHIDType">KeyboardHIDType</link></entry>
5835 </row>
5836 <row>
5837 <entry>IPciAddress</entry>
5838 <entry><link linkend="IPCIAddress">IPCIAddress</link></entry>
5839 </row>
5840 <row>
5841 <entry>IPciDeviceAttachment</entry>
5842 <entry><link linkend="IPCIDeviceAttachment">IPCIDeviceAttachment</link></entry>
5843 </row>
5844 <row>
5845 <entry>IMachine::pointingHidType</entry>
5846 <entry><link linkend="IMachine__pointingHIDType">IMachine::pointingHIDType</link></entry>
5847 </row>
5848 <row>
5849 <entry>IMachine::keyboardHidType</entry>
5850 <entry><link linkend="IMachine__keyboardHIDType">IMachine::keyboardHIDType</link></entry>
5851 </row>
5852 <row>
5853 <entry>IMachine::hpetEnabled</entry>
5854 <entry>IMachine::HPETEnabled</entry>
5855 </row>
5856 <row>
5857 <entry>IMachine::sessionPid</entry>
5858 <entry><link linkend="IMachine__sessionPID">IMachine::sessionPID</link></entry>
5859 </row>
5860 <row>
5861 <entry>IMachine::ioCacheEnabled</entry>
5862 <entry><link linkend="IMachine__IOCacheEnabled">IMachine::IOCacheEnabled</link></entry>
5863 </row>
5864 <row>
5865 <entry>IMachine::ioCacheSize</entry>
5866 <entry><link linkend="IMachine__IOCacheSize">IMachine::IOCacheSize</link></entry>
5867 </row>
5868 <row>
5869 <entry>IMachine::pciDeviceAssignments</entry>
5870 <entry><link linkend="IMachine__PCIDeviceAssignments">IMachine::PCIDeviceAssignments</link></entry>
5871 </row>
5872 <row>
5873 <entry>IMachine::attachHostPciDevice()</entry>
5874 <entry><link linkend="IMachine__attachHostPCIDevice">IMachine::attachHostPCIDevice</link></entry>
5875 </row>
5876 <row>
5877 <entry>IMachine::detachHostPciDevice()</entry>
5878 <entry><link linkend="IMachine__detachHostPCIDevice">IMachine::detachHostPCIDevice()</link></entry>
5879 </row>
5880 <row>
5881 <entry>IConsole::attachedPciDevices</entry>
5882 <entry><link linkend="IConsole__attachedPCIDevices">IConsole::attachedPCIDevices</link></entry>
5883 </row>
5884 <row>
5885 <entry>IHostNetworkInterface::dhcpEnabled</entry>
5886 <entry><link linkend="IHostNetworkInterface__DHCPEnabled">IHostNetworkInterface::DHCPEnabled</link></entry>
5887 </row>
5888 <row>
5889 <entry>IHostNetworkInterface::enableStaticIpConfig()</entry>
5890 <entry><link linkend="IHostNetworkInterface__enableStaticIPConfig">IHostNetworkInterface::enableStaticIPConfig()</link></entry>
5891 </row>
5892 <row>
5893 <entry>IHostNetworkInterface::enableStaticIpConfigV6()</entry>
5894 <entry><link linkend="IHostNetworkInterface__enableStaticIPConfigV6">IHostNetworkInterface::enableStaticIPConfigV6()</link></entry>
5895 </row>
5896 <row>
5897 <entry>IHostNetworkInterface::enableDynamicIpConfig()</entry>
5898 <entry><link linkend="IHostNetworkInterface__enableDynamicIPConfig">IHostNetworkInterface::enableDynamicIPConfig()</link></entry>
5899 </row>
5900 <row>
5901 <entry>IHostNetworkInterface::dhcpRediscover()</entry>
5902 <entry><link linkend="IHostNetworkInterface__DHCPRediscover">IHostNetworkInterface::DHCPRediscover()</link></entry>
5903 </row>
5904 <row>
5905 <entry>IHost::Acceleration3DAvailable</entry>
5906 <entry><link linkend="IHost__acceleration3DAvailable">IHost::acceleration3DAvailable</link></entry>
5907 </row>
5908 <row>
5909 <entry>IGuestOSType::recommendedPae</entry>
5910 <entry><link linkend="IGuestOSType__recommendedPAE">IGuestOSType::recommendedPAE</link></entry>
5911 </row>
5912 <row>
5913 <entry>IGuestOSType::recommendedDvdStorageController</entry>
5914 <entry><link linkend="IGuestOSType__recommendedDVDStorageController">IGuestOSType::recommendedDVDStorageController</link></entry>
5915 </row>
5916 <row>
5917 <entry>IGuestOSType::recommendedDvdStorageBus</entry>
5918 <entry><link linkend="IGuestOSType__recommendedDVDStorageBus">IGuestOSType::recommendedDVDStorageBus</link></entry>
5919 </row>
5920 <row>
5921 <entry>IGuestOSType::recommendedHdStorageController</entry>
5922 <entry><link linkend="IGuestOSType__recommendedHDStorageController">IGuestOSType::recommendedHDStorageController</link></entry>
5923 </row>
5924 <row>
5925 <entry>IGuestOSType::recommendedHdStorageBus</entry>
5926 <entry><link linkend="IGuestOSType__recommendedHDStorageBus">IGuestOSType::recommendedHDStorageBus</link></entry>
5927 </row>
5928 <row>
5929 <entry>IGuestOSType::recommendedUsbHid</entry>
5930 <entry><link linkend="IGuestOSType__recommendedUSBHID">IGuestOSType::recommendedUSBHID</link></entry>
5931 </row>
5932 <row>
5933 <entry>IGuestOSType::recommendedHpet</entry>
5934 <entry><link linkend="IGuestOSType__recommendedHPET">IGuestOSType::recommendedHPET</link></entry>
5935 </row>
5936 <row>
5937 <entry>IGuestOSType::recommendedUsbTablet</entry>
5938 <entry><link linkend="IGuestOSType__recommendedUSBTablet">IGuestOSType::recommendedUSBTablet</link></entry>
5939 </row>
5940 <row>
5941 <entry>IGuestOSType::recommendedRtcUseUtc</entry>
5942 <entry><link linkend="IGuestOSType__recommendedRTCUseUTC">IGuestOSType::recommendedRTCUseUTC</link></entry>
5943 </row>
5944 <row>
5945 <entry>IGuestOSType::recommendedUsb</entry>
5946 <entry><link linkend="IGuestOSType__recommendedUSB">IGuestOSType::recommendedUSB</link></entry>
5947 </row>
5948 <row>
5949 <entry>INetworkAdapter::natDriver</entry>
5950 <entry><link linkend="INetworkAdapter__NATEngine">INetworkAdapter::NATEngine</link></entry>
5951 </row>
5952 <row>
5953 <entry>IUSBController::enabledEhci</entry>
5954 <entry>IUSBController::enabledEHCI"</entry>
5955 </row>
5956 <row>
5957 <entry>INATEngine::tftpPrefix</entry>
5958 <entry><link linkend="INATEngine__TFTPPrefix">INATEngine::TFTPPrefix</link></entry>
5959 </row>
5960 <row>
5961 <entry>INATEngine::tftpBootFile</entry>
5962 <entry><link linkend="INATEngine__TFTPBootFile">INATEngine::TFTPBootFile</link></entry>
5963 </row>
5964 <row>
5965 <entry>INATEngine::tftpNextServer</entry>
5966 <entry><link linkend="INATEngine__TFTPNextServer">INATEngine::TFTPNextServer</link></entry>
5967 </row>
5968 <row>
5969 <entry>INATEngine::dnsPassDomain</entry>
5970 <entry><link linkend="INATEngine__DNSPassDomain">INATEngine::DNSPassDomain</link></entry>
5971 </row>
5972 <row>
5973 <entry>INATEngine::dnsProxy</entry>
5974 <entry><link linkend="INATEngine__DNSProxy">INATEngine::DNSProxy</link></entry>
5975 </row>
5976 <row>
5977 <entry>INATEngine::dnsUseHostResolver</entry>
5978 <entry><link linkend="INATEngine__DNSUseHostResolver">INATEngine::DNSUseHostResolver</link></entry>
5979 </row>
5980 <row>
5981 <entry>VBoxEventType::OnHostPciDevicePlug</entry>
5982 <entry><link linkend="VBoxEventType__OnHostPCIDevicePlug">VBoxEventType::OnHostPCIDevicePlug</link></entry>
5983 </row>
5984 <row>
5985 <entry>ICPUChangedEvent::cpu</entry>
5986 <entry><link linkend="ICPUChangedEvent__CPU">ICPUChangedEvent::CPU</link></entry>
5987 </row>
5988 <row>
5989 <entry>INATRedirectEvent::hostIp</entry>
5990 <entry><link linkend="INATRedirectEvent__hostIP">INATRedirectEvent::hostIP</link></entry>
5991 </row>
5992 <row>
5993 <entry>INATRedirectEvent::guestIp</entry>
5994 <entry><link linkend="INATRedirectEvent__guestIP">INATRedirectEvent::guestIP</link></entry>
5995 </row>
5996 <row>
5997 <entry>IHostPciDevicePlugEvent</entry>
5998 <entry><link linkend="IHostPCIDevicePlugEvent">IHostPCIDevicePlugEvent</link></entry>
5999 </row>
6000 </tbody>
6001 </tgroup></table></para>
6002 </listitem>
6003 </itemizedlist>
6004 </sect1>
6005
6006 <sect1>
6007 <title>Incompatible API changes with version 4.1</title>
6008
6009 <itemizedlist>
6010 <listitem>
6011 <para>The method
6012 <link linkend="IAppliance__importMachines">IAppliance::importMachines()</link>
6013 has one more parameter now, which allows to configure the import
6014 process in more detail.
6015 </para>
6016 </listitem>
6017
6018 <listitem>
6019 <para>The method
6020 <link linkend="IVirtualBox__openMedium">IVirtualBox::openMedium()</link>
6021 has one more parameter now, which allows resolving duplicate medium
6022 UUIDs without the need for external tools.</para>
6023 </listitem>
6024
6025 <listitem>
6026 <para>The <link linkend="INetworkAdapter">INetworkAdapter</link>
6027 interface has been cleaned up. The various methods to activate an
6028 attachment type have been replaced by the
6029 <link linkend="INetworkAdapter__attachmentType">INetworkAdapter::attachmentType</link>
6030 setter.</para>
6031 <para>Additionally each attachment mode now has its own attribute,
6032 which means that host only networks no longer share the settings with
6033 bridged interfaces.</para>
6034 <para>To allow introducing new network attachment implementations
6035 without making API changes, the concept of a generic network
6036 attachment driver has been introduced, which is configurable through
6037 key/value properties.</para>
6038 </listitem>
6039
6040 <listitem>
6041 <para>This version introduces the guest facilities concept. A guest
6042 facility either represents a module or feature the guest is running
6043 or offering, which is defined by
6044 <link linkend="AdditionsFacilityType">AdditionsFacilityType</link>.
6045 Each facility is member of a
6046 <link linkend="AdditionsFacilityClass">AdditionsFacilityClass</link>
6047 and has a current status indicated by
6048 <link linkend="AdditionsFacilityStatus">AdditionsFacilityStatus</link>,
6049 together with a timestamp (in ms) of the last status update.</para>
6050 <para>To address the above concept, the following changes were made:
6051 <itemizedlist>
6052 <listitem>
6053 <para>
6054 In the <link linkend="IGuest">IGuest</link> interface, the
6055 following were removed:
6056 <itemizedlist>
6057 <listitem>
6058 <para>the
6059 <computeroutput>supportsSeamless</computeroutput>
6060 attribute;</para>
6061 </listitem>
6062 <listitem>
6063 <para>the
6064 <computeroutput>supportsGraphics</computeroutput>
6065 attribute;</para>
6066 </listitem>
6067 </itemizedlist>
6068 </para>
6069 </listitem>
6070 <listitem>
6071 <para>
6072 The function
6073 <link linkend="IGuest__getFacilityStatus">IGuest::getFacilityStatus()</link>
6074 was added. It quickly provides a facility's status without
6075 the need to get the facility collection with
6076 <link linkend="IGuest__facilities">IGuest::facilities</link>.
6077 </para>
6078 </listitem>
6079 <listitem>
6080 <para>
6081 The attribute
6082 <link linkend="IGuest__facilities">IGuest::facilities</link>
6083 was added to provide an easy to access collection of all
6084 currently known guest facilities, that is, it contains all
6085 facilies where at least one status update was made since the
6086 guest was started.
6087 </para>
6088 </listitem>
6089 <listitem>
6090 <para>
6091 The interface
6092 <link linkend="IAdditionsFacility">IAdditionsFacility</link>
6093 was added to represent a single facility returned by
6094 <link linkend="IGuest__facilities">IGuest::facilities</link>.
6095 </para>
6096 </listitem>
6097 <listitem>
6098 <para>
6099 <link linkend="AdditionsFacilityStatus">AdditionsFacilityStatus</link>
6100 was added to represent a facility's overall status.
6101 </para>
6102 </listitem>
6103 <listitem>
6104 <para>
6105 <link linkend="AdditionsFacilityType">AdditionsFacilityType</link> and
6106 <link linkend="AdditionsFacilityClass">AdditionsFacilityClass</link> were
6107 added to represent the facility's type and class.
6108 </para>
6109 </listitem>
6110 </itemizedlist>
6111 </para>
6112 </listitem>
6113 </itemizedlist>
6114 </sect1>
6115
6116 <sect1>
6117 <title>Incompatible API changes with version 4.0</title>
6118
6119 <itemizedlist>
6120 <listitem>
6121 <para>A new Java glue layer replacing the previous OOWS JAX-WS
6122 bindings was introduced. The new library allows for uniform code
6123 targeting both local (COM/XPCOM) and remote (SOAP) transports. Now,
6124 instead of <computeroutput>IWebsessionManager</computeroutput>, the
6125 new class <computeroutput>VirtualBoxManager</computeroutput> must be
6126 used. See <xref linkend="javaapi"/> for details.</para>
6127 </listitem>
6128
6129 <listitem>
6130 <para>The confusingly named and impractical session APIs were
6131 changed. In existing client code, the following changes need to be
6132 made:<itemizedlist>
6133 <listitem>
6134 <para>Replace any
6135 <computeroutput>IVirtualBox::openSession(uuidMachine,
6136 ...)</computeroutput> API call with the machine's
6137 <link linkend="IMachine__lockMachine">IMachine::lockMachine()</link>
6138 call and a
6139 <computeroutput>LockType.Write</computeroutput> argument. The
6140 functionality is unchanged, but instead of "opening a direct
6141 session on a machine" all documentation now refers to
6142 "obtaining a write lock on a machine for the client
6143 session".</para>
6144 </listitem>
6145
6146 <listitem>
6147 <para>Similarly, replace any
6148 <computeroutput>IVirtualBox::openExistingSession(uuidMachine,
6149 ...)</computeroutput> call with the machine's
6150 <link linkend="IMachine__lockMachine">IMachine::lockMachine()</link>
6151 call and a <computeroutput>LockType.Shared</computeroutput>
6152 argument. Whereas it was previously impossible to connect a
6153 client session to a running VM process in a race-free manner,
6154 the new API will atomically either write-lock the machine for
6155 the current session or establish a remote link to an existing
6156 session. Existing client code which tried calling both
6157 <computeroutput>openSession()</computeroutput> and
6158 <computeroutput>openExistingSession()</computeroutput> can now
6159 use this one call instead.</para>
6160 </listitem>
6161
6162 <listitem>
6163 <para>Third, replace any
6164 <computeroutput>IVirtualBox::openRemoteSession(uuidMachine,
6165 ...)</computeroutput> call with the machine's
6166 <link linkend="IMachine__launchVMProcess">IMachine::launchVMProcess()</link>
6167 call. The functionality is unchanged.</para>
6168 </listitem>
6169
6170 <listitem>
6171 <para>The <link linkend="SessionState">SessionState</link> enum
6172 was adjusted accordingly: "Open" is now "Locked", "Closed" is
6173 now "Unlocked", "Closing" is now "Unlocking".</para>
6174 </listitem>
6175 </itemizedlist></para>
6176 </listitem>
6177
6178 <listitem>
6179 <para>Virtual machines created with VirtualBox 4.0 or later no
6180 longer register their media in the global media registry in the
6181 <computeroutput>VirtualBox.xml</computeroutput> file. Instead, such
6182 machines list all their media in their own machine XML files. As a
6183 result, a number of media-related APIs had to be modified again.
6184 <itemizedlist>
6185 <listitem>
6186 <para>Neither
6187 <computeroutput>IVirtualBox::createHardDisk()</computeroutput>
6188 nor
6189 <link linkend="IVirtualBox__openMedium">IVirtualBox::openMedium()</link>
6190 register media automatically any more.</para>
6191 </listitem>
6192
6193 <listitem>
6194 <para><link linkend="IMachine__attachDevice">IMachine::attachDevice()</link>
6195 and
6196 <link linkend="IMachine__mountMedium">IMachine::mountMedium()</link>
6197 now take an IMedium object instead of a UUID as an argument. It
6198 is these two calls which add media to a registry now (either a
6199 machine registry for machines created with VirtualBox 4.0 or
6200 later or the global registry otherwise). As a consequence, if a
6201 medium is opened but never attached to a machine, it is no
6202 longer added to any registry any more.</para>
6203 </listitem>
6204
6205 <listitem>
6206 <para>To reduce code duplication, the APIs
6207 IVirtualBox::findHardDisk(), getHardDisk(), findDVDImage(),
6208 getDVDImage(), findFloppyImage() and getFloppyImage() have all
6209 been merged into IVirtualBox::findMedium(), and
6210 IVirtualBox::openHardDisk(), openDVDImage() and
6211 openFloppyImage() have all been merged into
6212 <link linkend="IVirtualBox__openMedium">IVirtualBox::openMedium()</link>.</para>
6213 </listitem>
6214
6215 <listitem>
6216 <para>The rare use case of changing the UUID and parent UUID
6217 of a medium previously handled by
6218 <computeroutput>openHardDisk()</computeroutput> is now in a
6219 separate IMedium::setIDs method.</para>
6220 </listitem>
6221
6222 <listitem>
6223 <para><computeroutput>ISystemProperties::get/setDefaultHardDiskFolder()</computeroutput>
6224 have been removed since disk images are now by default placed
6225 in each machine's folder.</para>
6226 </listitem>
6227
6228 <listitem>
6229 <para>The
6230 <link linkend="ISystemProperties__infoVDSize">ISystemProperties::infoVDSize</link>
6231 attribute replaces the
6232 <computeroutput>getMaxVDISize()</computeroutput>
6233 API call; this now uses bytes instead of megabytes.</para>
6234 </listitem>
6235 </itemizedlist></para>
6236 </listitem>
6237
6238 <listitem>
6239 <para>Machine management APIs were enhanced as follows:<itemizedlist>
6240 <listitem>
6241 <para><link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
6242 is no longer restricted to creating machines in the default
6243 "Machines" folder, but can now create machines at arbitrary
6244 locations. For this to work, the parameter list had to be
6245 changed.</para>
6246 </listitem>
6247
6248 <listitem>
6249 <para>The long-deprecated
6250 <computeroutput>IVirtualBox::createLegacyMachine()</computeroutput>
6251 API has been removed.</para>
6252 </listitem>
6253
6254 <listitem>
6255 <para>To reduce code duplication and for consistency with the
6256 aforementioned media APIs,
6257 <computeroutput>IVirtualBox::getMachine()</computeroutput> has
6258 been merged with
6259 <link linkend="IVirtualBox__findMachine">IVirtualBox::findMachine()</link>,
6260 and
6261 <computeroutput>IMachine::getSnapshot()</computeroutput> has
6262 been merged with
6263 <link linkend="IMachine__findSnapshot">IMachine::findSnapshot()</link>.</para>
6264 </listitem>
6265
6266 <listitem>
6267 <para><computeroutput>IVirtualBox::unregisterMachine()</computeroutput>
6268 was replaced with
6269 <link linkend="IMachine__unregister">IMachine::unregister()</link>
6270 with additional functionality for cleaning up machine
6271 files.</para>
6272 </listitem>
6273
6274 <listitem>
6275 <para><computeroutput>IMachine::deleteSettings</computeroutput>
6276 has been replaced by IMachine::delete, which allows specifying
6277 which disk images are to be deleted as part of the deletion,
6278 and because it can take a while it also returns a
6279 <computeroutput>IProgress</computeroutput> object reference,
6280 so that the completion of the asynchronous activities can be
6281 monitored.</para>
6282 </listitem>
6283
6284 <listitem>
6285 <para><computeroutput>IConsole::forgetSavedState</computeroutput>
6286 has been renamed to
6287 <computeroutput>IConsole::discardSavedState()</computeroutput>.</para>
6288 </listitem>
6289 </itemizedlist></para>
6290 </listitem>
6291
6292 <listitem>
6293 <para>All event callbacks APIs were replaced with a new, generic
6294 event mechanism that can be used both locally (COM, XPCOM) and
6295 remotely (web services). Also, the new mechanism is usable from
6296 scripting languages and a local Java. See
6297 <link linkend="IEvent">events</link> for details. The new concept
6298 will require changes to all clients that used event callbacks.</para>
6299 </listitem>
6300
6301 <listitem>
6302 <para><computeroutput>additionsActive()</computeroutput> was replaced
6303 with
6304 <link linkend="IGuest__additionsRunLevel">additionsRunLevel()</link>
6305 and
6306 <link linkend="IGuest__getAdditionsStatus">getAdditionsStatus()</link>
6307 in order to support a more detailed status of the current Guest
6308 Additions loading/readiness state.
6309 <link linkend="IGuest__additionsVersion">IGuest::additionsVersion()</link>
6310 no longer returns the Guest Additions interface version but the
6311 installed Guest Additions version and revision in form of
6312 <computeroutput>3.3.0r12345</computeroutput>.</para>
6313 </listitem>
6314
6315 <listitem>
6316 <para>To address shared folders auto-mounting support, the following
6317 APIs were extended to require an additional
6318 <computeroutput>automount</computeroutput> parameter: <itemizedlist>
6319 <listitem>
6320 <para><link linkend="IVirtualBox__createSharedFolder">IVirtualBox::createSharedFolder()</link></para>
6321 </listitem>
6322
6323 <listitem>
6324 <para><link linkend="IMachine__createSharedFolder">IMachine::createSharedFolder()</link></para>
6325 </listitem>
6326
6327 <listitem>
6328 <para><link linkend="IConsole__createSharedFolder">IConsole::createSharedFolder()</link></para>
6329 </listitem>
6330 </itemizedlist> Also, a new property named
6331 <computeroutput>autoMount</computeroutput> was added to the
6332 <link linkend="ISharedFolder">ISharedFolder</link>
6333 interface.</para>
6334 </listitem>
6335
6336 <listitem>
6337 <para>The appliance (OVF) APIs were enhanced as
6338 follows:<itemizedlist>
6339 <listitem>
6340 <para><computeroutput>IMachine::export</computeroutput>
6341 received an extra parameter
6342 <computeroutput>location</computeroutput>, which is used to
6343 decide for the disk naming.</para>
6344 </listitem>
6345
6346 <listitem>
6347 <para><link linkend="IAppliance__write">IAppliance::write()</link>
6348 received an extra parameter
6349 <computeroutput>manifest</computeroutput>, which can suppress
6350 creating the manifest file on export.</para>
6351 </listitem>
6352
6353 <listitem>
6354 <para><link linkend="IVFSExplorer__entryList">IVFSExplorer::entryList()</link>
6355 received two extra parameters
6356 <computeroutput>sizes</computeroutput> and
6357 <computeroutput>modes</computeroutput>, which contains the
6358 sizes (in bytes) and the file access modes (in octal form) of
6359 the returned files.</para>
6360 </listitem>
6361 </itemizedlist></para>
6362 </listitem>
6363
6364 <listitem>
6365 <para>Support for remote desktop access to virtual machines has been
6366 cleaned up to allow third party implementations of the remote
6367 desktop server. This is called the VirtualBox Remote Desktop
6368 Extension (VRDE) and can be added to VirtualBox by installing the
6369 corresponding extension package; see the VirtualBox User Guide for
6370 details.</para>
6371
6372 <para>The following API changes were made to support the VRDE
6373 interface: <itemizedlist>
6374 <listitem>
6375 <para><computeroutput>IVRDPServer</computeroutput> has been
6376 renamed to
6377 <link linkend="IVRDEServer">IVRDEServer</link>.</para>
6378 </listitem>
6379
6380 <listitem>
6381 <para><computeroutput>IRemoteDisplayInfo</computeroutput> has
6382 been renamed to
6383 <link linkend="IVRDEServerInfo">IVRDEServerInfo</link>.</para>
6384 </listitem>
6385
6386 <listitem>
6387 <para><link linkend="IMachine__VRDEServer">IMachine::VRDEServer</link>
6388 replaces
6389 <computeroutput>VRDPServer.</computeroutput></para>
6390 </listitem>
6391
6392 <listitem>
6393 <para><link linkend="IConsole__VRDEServerInfo">IConsole::VRDEServerInfo</link>
6394 replaces
6395 <computeroutput>RemoteDisplayInfo</computeroutput>.</para>
6396 </listitem>
6397
6398 <listitem>
6399 <para><link linkend="ISystemProperties__VRDEAuthLibrary">ISystemProperties::VRDEAuthLibrary</link>
6400 replaces
6401 <computeroutput>RemoteDisplayAuthLibrary</computeroutput>.</para>
6402 </listitem>
6403
6404 <listitem>
6405 <para>The following methods have been implemented in
6406 <computeroutput>IVRDEServer</computeroutput> to support
6407 generic VRDE properties: <itemizedlist>
6408 <listitem>
6409 <para><link linkend="IVRDEServer__setVRDEProperty">IVRDEServer::setVRDEProperty</link></para>
6410 </listitem>
6411
6412 <listitem>
6413 <para><link linkend="IVRDEServer__getVRDEProperty">IVRDEServer::getVRDEProperty</link></para>
6414 </listitem>
6415
6416 <listitem>
6417 <para><link linkend="IVRDEServer__VRDEProperties">IVRDEServer::VRDEProperties</link></para>
6418 </listitem>
6419 </itemizedlist></para>
6420
6421 <para>A few implementation-specific attributes of the old
6422 <computeroutput>IVRDPServer</computeroutput> interface have
6423 been removed and replaced with properties: <itemizedlist>
6424 <listitem>
6425 <para><computeroutput>IVRDPServer::Ports</computeroutput>
6426 has been replaced with the
6427 <computeroutput>"TCP/Ports"</computeroutput> property.
6428 The property value is a string, which contains a
6429 comma-separated list of ports or ranges of ports. Use a
6430 dash between two port numbers to specify a range.
6431 Example:
6432 <computeroutput>"5000,5010-5012"</computeroutput></para>
6433 </listitem>
6434
6435 <listitem>
6436 <para><computeroutput>IVRDPServer::NetAddress</computeroutput>
6437 has been replaced with the
6438 <computeroutput>"TCP/Address"</computeroutput> property.
6439 The property value is an IP address string. Example:
6440 <computeroutput>"127.0.0.1"</computeroutput></para>
6441 </listitem>
6442
6443 <listitem>
6444 <para><computeroutput>IVRDPServer::VideoChannel</computeroutput>
6445 has been replaced with the
6446 <computeroutput>"VideoChannel/Enabled"</computeroutput>
6447 property. The property value is either
6448 <computeroutput>"true"</computeroutput> or
6449 <computeroutput>"false"</computeroutput></para>
6450 </listitem>
6451
6452 <listitem>
6453 <para><computeroutput>IVRDPServer::VideoChannelQuality</computeroutput>
6454 has been replaced with the
6455 <computeroutput>"VideoChannel/Quality"</computeroutput>
6456 property. The property value is a string which contain a
6457 decimal number in range 10..100. Invalid values are
6458 ignored and the quality is set to the default value 75.
6459 Example: <computeroutput>"50"</computeroutput></para>
6460 </listitem>
6461 </itemizedlist></para>
6462 </listitem>
6463 </itemizedlist></para>
6464 </listitem>
6465
6466 <listitem>
6467 <para>The VirtualBox external authentication module interface has
6468 been updated and made more generic. Because of that,
6469 <computeroutput>VRDPAuthType</computeroutput> enumeration has been
6470 renamed to <link linkend="AuthType">AuthType</link>.</para>
6471 </listitem>
6472 </itemizedlist>
6473 </sect1>
6474
6475 <sect1>
6476 <title>Incompatible API changes with version 3.2</title>
6477
6478 <itemizedlist>
6479 <listitem>
6480 <para>The following interfaces were renamed for consistency:
6481 <itemizedlist>
6482 <listitem>
6483 <para>IMachine::getCpuProperty() is now IMachine::getCPUProperty();</para>
6484 </listitem>
6485
6486 <listitem>
6487 <para>IMachine::setCpuProperty() is now IMachine::setCPUProperty();</para>
6488 </listitem>
6489
6490 <listitem>
6491 <para>IMachine::getCpuIdLeaf() is now IMachine::getCPUIDLeaf();</para>
6492 </listitem>
6493
6494 <listitem>
6495 <para>IMachine::setCpuIdLeaf() is now IMachine::setCPUIDLeaf();</para>
6496 </listitem>
6497
6498 <listitem>
6499 <para>IMachine::removeCpuIdLeaf() is now IMachine::removeCPUIDLeaf();</para>
6500 </listitem>
6501
6502 <listitem>
6503 <para>IMachine::removeAllCpuIdLeafs() is now IMachine::removeAllCPUIDLeaves();</para>
6504 </listitem>
6505
6506 <listitem>
6507 <para>the CpuPropertyType enum is now CPUPropertyType.</para>
6508 </listitem>
6509
6510 <listitem>
6511 <para>IVirtualBoxCallback::onSnapshotDiscarded() is now
6512 IVirtualBoxCallback::onSnapshotDeleted.</para>
6513 </listitem>
6514 </itemizedlist></para>
6515 </listitem>
6516
6517 <listitem>
6518 <para>When creating a VM configuration with
6519 <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
6520 it is now possible to ignore existing configuration files which would
6521 previously have caused a failure. For this the
6522 <computeroutput>override</computeroutput> parameter was added.</para>
6523 </listitem>
6524
6525 <listitem>
6526 <para>Deleting snapshots via
6527 <computeroutput>IConsole::deleteSnapshot()</computeroutput> is now
6528 possible while the associated VM is running in almost all cases.
6529 The API is unchanged, but client code that verifies machine states
6530 to determine whether snapshots can be deleted may need to be
6531 adjusted.</para>
6532 </listitem>
6533
6534 <listitem>
6535 <para>The IoBackendType enumeration was replaced with a boolean flag
6536 (see
6537 <link linkend="IStorageController__useHostIOCache">IStorageController::useHostIOCache</link>).</para>
6538 </listitem>
6539
6540 <listitem>
6541 <para>To address multi-monitor support, the following APIs were
6542 extended to require an additional
6543 <computeroutput>screenId</computeroutput> parameter: <itemizedlist>
6544 <listitem>
6545 <para>IMachine::querySavedThumbnailSize()</para>
6546 </listitem>
6547
6548 <listitem>
6549 <para><link linkend="IMachine__readSavedThumbnailToArray">IMachine::readSavedThumbnailToArray()</link></para>
6550 </listitem>
6551
6552 <listitem>
6553 <para><link linkend="IMachine__querySavedScreenshotInfo">IMachine::querySavedScreenshotPNGSize()</link></para>
6554 </listitem>
6555
6556 <listitem>
6557 <para><link linkend="IMachine__readSavedScreenshotToArray">IMachine::readSavedScreenshotPNGToArray()</link></para>
6558 </listitem>
6559 </itemizedlist></para>
6560 </listitem>
6561
6562 <listitem>
6563 <para>The <computeroutput>shape</computeroutput> parameter of
6564 IConsoleCallback::onMousePointerShapeChange was changed from a
6565 implementation-specific pointer to a safearray, enabling scripting
6566 languages to process pointer shapes.</para>
6567 </listitem>
6568 </itemizedlist>
6569 </sect1>
6570
6571 <sect1>
6572 <title>Incompatible API changes with version 3.1</title>
6573
6574 <itemizedlist>
6575 <listitem>
6576 <para>Due to the new flexibility in medium attachments that was
6577 introduced with version 3.1 (in particular, full flexibility with
6578 attaching CD/DVD drives to arbitrary controllers), we seized the
6579 opportunity to rework all interfaces dealing with storage media to
6580 make the API more flexible as well as logical. The
6581 <link linkend="IStorageController">IStorageController</link>,
6582 <link linkend="IMedium">IMedium</link>,
6583 <link linkend="IMediumAttachment">IMediumAttachment</link> and
6584 <link linkend="IMachine">IMachine</link> interfaces were
6585 affected the most. Existing code using them to configure storage and
6586 media needs to be carefully checked.</para>
6587
6588 <para>All media (hard disks, floppies and CDs/DVDs) are now
6589 uniformly handled through the <link linkend="IMedium">IMedium</link>
6590 interface. The device-specific interfaces
6591 (<code>IHardDisk</code>, <code>IDVDImage</code>,
6592 <code>IHostDVDDrive</code>, <code>IFloppyImage</code> and
6593 <code>IHostFloppyDrive</code>) have been merged into IMedium; CD/DVD
6594 and floppy media no longer need special treatment. The device type
6595 of a medium determines in which context it can be used. Some
6596 functionality was moved to the other storage-related
6597 interfaces.</para>
6598
6599 <para><code>IMachine::attachHardDisk</code> and similar methods have
6600 been renamed and generalized to deal with any type of drive and
6601 medium.
6602 <link linkend="IMachine__attachDevice">IMachine::attachDevice()</link>
6603 is the API method for adding any drive to a storage controller. The
6604 floppy and DVD/CD drives are no longer handled specially, and that
6605 means you can have more than one of them. As before, drives can only
6606 be changed while the VM is powered off. Mounting (or unmounting)
6607 removable media at runtime is possible with
6608 <link linkend="IMachine__mountMedium">IMachine::mountMedium()</link>.</para>
6609
6610 <para>Newly created virtual machines have no storage controllers
6611 associated with them. Even the IDE Controller needs to be created
6612 explicitly. The floppy controller is now visible as a separate
6613 controller, with a new storage bus type. For each storage bus type
6614 you can query the device types which can be attached, so that it is
6615 not necessary to hardcode any attachment rules.</para>
6616
6617 <para>This required matching changes e.g. in the callback interfaces
6618 (the medium specific change notification was replaced by a generic
6619 medium change notification) and removing associated enums (e.g.
6620 <code>DriveState</code>). In many places the incorrect use of the
6621 plural form "media" was replaced by "medium", to improve
6622 consistency.</para>
6623 </listitem>
6624
6625 <listitem>
6626 <para>Reading the
6627 <link linkend="IMedium__state">IMedium::state</link> attribute no
6628 longer automatically performs an accessibility check; a new method
6629 <link linkend="IMedium__refreshState">IMedium::refreshState()</link>
6630 does this. The attribute only returns the state now.</para>
6631 </listitem>
6632
6633 <listitem>
6634 <para>There were substantial changes related to snapshots, triggered
6635 by the "branched snapshots" functionality introduced with version
6636 3.1. IConsole::discardSnapshot was renamed to
6637 <computeroutput>IConsole::deleteSnapshot()</computeroutput>.
6638 IConsole::discardCurrentState and
6639 IConsole::discardCurrentSnapshotAndState were removed; corresponding
6640 new functionality is in
6641 <computeroutput>IConsole::restoreSnapshot()</computeroutput>.
6642 Also, when <computeroutput>IConsole::takeSnapshot()</computeroutput>
6643 is called on a running virtual machine, a live snapshot will be
6644 created. The old behavior was to temporarily pause the virtual
6645 machine while creating an online snapshot.</para>
6646 </listitem>
6647
6648 <listitem>
6649 <para>The <computeroutput>IVRDPServer</computeroutput>,
6650 <computeroutput>IRemoteDisplayInfo"</computeroutput> and
6651 <computeroutput>IConsoleCallback</computeroutput> interfaces were
6652 changed to reflect VRDP server ability to bind to one of available
6653 ports from a list of ports.</para>
6654
6655 <para>The <computeroutput>IVRDPServer::port</computeroutput>
6656 attribute has been replaced with
6657 <computeroutput>IVRDPServer::ports</computeroutput>, which is a
6658 comma-separated list of ports or ranges of ports.</para>
6659
6660 <para>An <computeroutput>IRemoteDisplayInfo::port"</computeroutput>
6661 attribute has been added for querying the actual port VRDP server
6662 listens on.</para>
6663
6664 <para>An IConsoleCallback::onRemoteDisplayInfoChange() notification
6665 callback has been added.</para>
6666 </listitem>
6667
6668 <listitem>
6669 <para>The parameter lists for the following functions were
6670 modified:<itemizedlist>
6671 <listitem>
6672 <para><link linkend="IHost__removeHostOnlyNetworkInterface">IHost::removeHostOnlyNetworkInterface()</link></para>
6673 </listitem>
6674
6675 <listitem>
6676 <para><link linkend="IHost__removeUSBDeviceFilter">IHost::removeUSBDeviceFilter()</link></para>
6677 </listitem>
6678 </itemizedlist></para>
6679 </listitem>
6680
6681 <listitem>
6682 <para>In the OOWS bindings for JAX-WS, the behavior of structures
6683 changed: for one, we implemented natural structures field access so
6684 you can just call a "get" method to obtain a field. Secondly,
6685 setters in structures were disabled as they have no expected effect
6686 and were at best misleading.</para>
6687 </listitem>
6688 </itemizedlist>
6689 </sect1>
6690
6691 <sect1>
6692 <title>Incompatible API changes with version 3.0</title>
6693
6694 <itemizedlist>
6695 <listitem>
6696 <para>In the object-oriented web service bindings for JAX-WS, proper
6697 inheritance has been introduced for some classes, so explicit
6698 casting is no longer needed to call methods from a parent class. In
6699 particular, IHardDisk and other classes now properly derive from
6700 <link linkend="IMedium">IMedium</link>.</para>
6701 </listitem>
6702
6703 <listitem>
6704 <para>All object identifiers (machines, snapshots, disks, etc)
6705 switched from GUIDs to strings (now still having string
6706 representation of GUIDs inside). As a result, no particular internal
6707 structure can be assumed for object identifiers; instead, they
6708 should be treated as opaque unique handles. This change mostly
6709 affects Java and C++ programs; for other languages, GUIDs are
6710 transparently converted to strings.</para>
6711 </listitem>
6712
6713 <listitem>
6714 <para>The uses of NULL strings have been changed greatly. All out
6715 parameters now use empty strings to signal a null value. For in
6716 parameters both the old NULL and empty string is allowed. This
6717 change was necessary to support more client bindings, especially
6718 using the web service API. Many of them either have no special NULL
6719 value or have trouble dealing with it correctly in the respective
6720 library code.</para>
6721 </listitem>
6722
6723 <listitem>
6724 <para>Accidentally, the <code>TSBool</code> interface still appeared
6725 in 3.0.0, and was removed in 3.0.2. This is an SDK bug, do not use
6726 the SDK for VirtualBox 3.0.0 for developing clients.</para>
6727 </listitem>
6728
6729 <listitem>
6730 <para>The type of
6731 <link linkend="IVirtualBoxErrorInfo__resultCode">IVirtualBoxErrorInfo::resultCode</link>
6732 changed from
6733 <computeroutput>result</computeroutput> to
6734 <computeroutput>long</computeroutput>.</para>
6735 </listitem>
6736
6737 <listitem>
6738 <para>The parameter list of IVirtualBox::openHardDisk was
6739 changed.</para>
6740 </listitem>
6741
6742 <listitem>
6743 <para>The method IConsole::discardSavedState was renamed to
6744 IConsole::forgetSavedState, and a parameter was added.</para>
6745 </listitem>
6746
6747 <listitem>
6748 <para>The method IConsole::powerDownAsync was renamed to
6749 <link linkend="IConsole__powerDown">IConsole::powerDown</link>,
6750 and the previous method with that name was deleted. So effectively a
6751 parameter was added.</para>
6752 </listitem>
6753
6754 <listitem>
6755 <para>In the
6756 <link linkend="IFramebuffer">IFramebuffer</link> interface, the
6757 following were removed:<itemizedlist>
6758 <listitem>
6759 <para>the <computeroutput>operationSupported</computeroutput>
6760 attribute;</para>
6761
6762 <para>(as a result, the
6763 <computeroutput>FramebufferAccelerationOperation</computeroutput>
6764 enum was no longer needed and removed as well);</para>
6765 </listitem>
6766
6767 <listitem>
6768 <para>the <computeroutput>solidFill()</computeroutput>
6769 method;</para>
6770 </listitem>
6771
6772 <listitem>
6773 <para>the <computeroutput>copyScreenBits()</computeroutput>
6774 method.</para>
6775 </listitem>
6776 </itemizedlist></para>
6777 </listitem>
6778
6779 <listitem>
6780 <para>In the <link linkend="IDisplay">IDisplay</link>
6781 interface, the following were removed:<itemizedlist>
6782 <listitem>
6783 <para>the
6784 <computeroutput>setupInternalFramebuffer()</computeroutput>
6785 method;</para>
6786 </listitem>
6787
6788 <listitem>
6789 <para>the <computeroutput>lockFramebuffer()</computeroutput>
6790 method;</para>
6791 </listitem>
6792
6793 <listitem>
6794 <para>the <computeroutput>unlockFramebuffer()</computeroutput>
6795 method;</para>
6796 </listitem>
6797
6798 <listitem>
6799 <para>the
6800 <computeroutput>registerExternalFramebuffer()</computeroutput>
6801 method.</para>
6802 </listitem>
6803 </itemizedlist></para>
6804 </listitem>
6805 </itemizedlist>
6806 </sect1>
6807
6808 <sect1>
6809 <title>Incompatible API changes with version 2.2</title>
6810
6811 <itemizedlist>
6812 <listitem>
6813 <para>Added explicit version number into JAX-WS Java package names,
6814 such as <computeroutput>org.virtualbox_2_2</computeroutput>,
6815 allowing connect to multiple VirtualBox clients from single Java
6816 application.</para>
6817 </listitem>
6818
6819 <listitem>
6820 <para>The interfaces having a "2" suffix attached to them with
6821 version 2.1 were renamed again to have that suffix removed. This
6822 time around, this change involves only the name, there are no
6823 functional differences.</para>
6824
6825 <para>As a result, IDVDImage2 is now IDVDImage; IHardDisk2 is now
6826 IHardDisk; IHardDisk2Attachment is now IHardDiskAttachment.</para>
6827
6828 <para>Consequentially, all related methods and attributes that had a
6829 "2" suffix have been renamed; for example, IMachine::attachHardDisk2
6830 now becomes IMachine::attachHardDisk().</para>
6831 </listitem>
6832
6833 <listitem>
6834 <para>IVirtualBox::openHardDisk has an extra parameter for opening a
6835 disk read/write or read-only.</para>
6836 </listitem>
6837
6838 <listitem>
6839 <para>The remaining collections were replaced by more performant
6840 safe-arrays. This affects the following collections:</para>
6841
6842 <itemizedlist>
6843 <listitem>
6844 <para>IGuestOSTypeCollection</para>
6845 </listitem>
6846
6847 <listitem>
6848 <para>IHostDVDDriveCollection</para>
6849 </listitem>
6850
6851 <listitem>
6852 <para>IHostFloppyDriveCollection</para>
6853 </listitem>
6854
6855 <listitem>
6856 <para>IHostUSBDeviceCollection</para>
6857 </listitem>
6858
6859 <listitem>
6860 <para>IHostUSBDeviceFilterCollection</para>
6861 </listitem>
6862
6863 <listitem>
6864 <para>IProgressCollection</para>
6865 </listitem>
6866
6867 <listitem>
6868 <para>ISharedFolderCollection</para>
6869 </listitem>
6870
6871 <listitem>
6872 <para>ISnapshotCollection</para>
6873 </listitem>
6874
6875 <listitem>
6876 <para>IUSBDeviceCollection</para>
6877 </listitem>
6878
6879 <listitem>
6880 <para>IUSBDeviceFilterCollection</para>
6881 </listitem>
6882 </itemizedlist>
6883 </listitem>
6884
6885 <listitem>
6886 <para>Since "Host Interface Networking" was renamed to "bridged
6887 networking" and host-only networking was introduced, all associated
6888 interfaces needed renaming as well. In detail:</para>
6889
6890 <itemizedlist>
6891 <listitem>
6892 <para>The HostNetworkInterfaceType enum has been renamed to
6893 <link linkend="HostNetworkInterfaceMediumType">HostNetworkInterfaceMediumType</link></para>
6894 </listitem>
6895
6896 <listitem>
6897 <para>The IHostNetworkInterface::type attribute has been renamed
6898 to
6899 <link linkend="IHostNetworkInterface__mediumType">IHostNetworkInterface::mediumType</link></para>
6900 </listitem>
6901
6902 <listitem>
6903 <para>INetworkAdapter::attachToHostInterface() has been renamed
6904 to INetworkAdapter::attachToBridgedInterface</para>
6905 </listitem>
6906
6907 <listitem>
6908 <para>In the IHost interface, createHostNetworkInterface() has
6909 been renamed to
6910 <link linkend="IHost__createHostOnlyNetworkInterface">createHostOnlyNetworkInterface()</link></para>
6911 </listitem>
6912
6913 <listitem>
6914 <para>Similarly, removeHostNetworkInterface() has been renamed
6915 to
6916 <link linkend="IHost__removeHostOnlyNetworkInterface">removeHostOnlyNetworkInterface()</link></para>
6917 </listitem>
6918 </itemizedlist>
6919 </listitem>
6920 </itemizedlist>
6921 </sect1>
6922
6923 <sect1>
6924 <title>Incompatible API changes with version 2.1</title>
6925
6926 <itemizedlist>
6927 <listitem>
6928 <para>With VirtualBox 2.1, error codes were added to many error
6929 infos that give the caller a machine-readable (numeric) feedback in
6930 addition to the error string that has always been available. This is
6931 an ongoing process, and future versions of this SDK reference will
6932 document the error codes for each method call.</para>
6933 </listitem>
6934
6935 <listitem>
6936 <para>The hard disk and other media interfaces were completely
6937 redesigned. This was necessary to account for the support of VMDK,
6938 VHD and other image types; since backwards compatibility had to be
6939 broken anyway, we seized the moment to redesign the interfaces in a
6940 more logical way.</para>
6941
6942 <itemizedlist>
6943 <listitem>
6944 <para>Previously, the old IHardDisk interface had several
6945 derivatives called IVirtualDiskImage, IVMDKImage, IVHDImage,
6946 IISCSIHardDisk and ICustomHardDisk for the various disk formats
6947 supported by VirtualBox. The new IHardDisk2 interface that comes
6948 with version 2.1 now supports all hard disk image formats
6949 itself.</para>
6950 </listitem>
6951
6952 <listitem>
6953 <para>IHardDiskFormat is a new interface to describe the
6954 available back-ends for hard disk images (e.g. VDI, VMDK, VHD or
6955 iSCSI). The IHardDisk2::format attribute can be used to find out
6956 the back-end that is in use for a particular hard disk image.
6957 ISystemProperties::hardDiskFormats[] contains a list of all
6958 back-ends supported by the system.
6959 <link linkend="ISystemProperties__defaultHardDiskFormat">ISystemProperties::defaultHardDiskFormat</link>
6960 contains the default system format.</para>
6961 </listitem>
6962
6963 <listitem>
6964 <para>In addition, the new
6965 <link linkend="IMedium">IMedium</link> interface is a generic
6966 interface for hard disk, DVD and floppy images that contains the
6967 attributes and methods shared between them. It can be considered
6968 a parent class of the more specific interfaces for those images,
6969 which are now IHardDisk2, IDVDImage2 and IFloppyImage2.</para>
6970
6971 <para>In each case, the "2" versions of these interfaces replace
6972 the earlier versions that did not have the "2" suffix.
6973 Previously, the IDVDImage and IFloppyImage interfaces were
6974 entirely unrelated to IHardDisk.</para>
6975 </listitem>
6976
6977 <listitem>
6978 <para>As a result, all parts of the API that previously
6979 referenced IHardDisk, IDVDImage or IFloppyImage or any of the
6980 old subclasses are gone and will have replacements that use
6981 IHardDisk2, IDVDImage2 and IFloppyImage2; see, for example,
6982 IMachine::attachHardDisk2.</para>
6983 </listitem>
6984
6985 <listitem>
6986 <para>In particular, the IVirtualBox::hardDisks2 array replaces
6987 the earlier IVirtualBox::hardDisks collection.</para>
6988 </listitem>
6989 </itemizedlist>
6990 </listitem>
6991
6992 <listitem>
6993 <para><link linkend="IGuestOSType">IGuestOSType</link> was
6994 extended to group operating systems into families and for 64-bit
6995 support.</para>
6996 </listitem>
6997
6998 <listitem>
6999 <para>The
7000 <link linkend="IHostNetworkInterface">IHostNetworkInterface</link>
7001 interface was completely rewritten to account for the changes in how
7002 Host Interface Networking is now implemented in VirtualBox
7003 2.1.</para>
7004 </listitem>
7005
7006 <listitem>
7007 <para>The IVirtualBox::machines2[] array replaces the former
7008 IVirtualBox::machines collection.</para>
7009 </listitem>
7010
7011 <listitem>
7012 <para>Added
7013 <link linkend="IHost__getProcessorFeature">IHost::getProcessorFeature()</link>
7014 and <link linkend="ProcessorFeature">ProcessorFeature</link>
7015 enumeration.</para>
7016 </listitem>
7017
7018 <listitem>
7019 <para>The parameter list for
7020 <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
7021 was modified.</para>
7022 </listitem>
7023
7024 <listitem>
7025 <para>Added IMachine::pushGuestProperty.</para>
7026 </listitem>
7027
7028 <listitem>
7029 <para>New attributes in IMachine: accelerate3DEnabled,
7030 HWVirtExVPIDEnabled,
7031 <computeroutput>IMachine::guestPropertyNotificationPatterns</computeroutput>,
7032 <link linkend="IMachine__CPUCount">CPUCount</link>.</para>
7033 </listitem>
7034
7035 <listitem>
7036 <para>Added
7037 <link linkend="IConsole__powerUpPaused">IConsole::powerUpPaused()</link>
7038 and
7039 <link linkend="IConsole__getGuestEnteredACPIMode">IConsole::getGuestEnteredACPIMode()</link>.</para>
7040 </listitem>
7041
7042 <listitem>
7043 <para>Removed ResourceUsage enumeration.</para>
7044 </listitem>
7045 </itemizedlist>
7046 </sect1>
7047 </chapter>
7048</book>
7049<!-- vim: set shiftwidth=2 tabstop=2 expandtab: -->
Note: See TracBrowser for help on using the repository browser.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette