VirtualBox

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

Last change on this file was 103553, checked in by vboxsync, 2 months ago

doc/SDKRef,Main/VirtualBox.xidl: Document the changes to the Main API
which added support for the ARM64 architecture. bugref:10508

  • Property svn:eol-style set to native
  • Property svn:keywords set to Id Revision
File size: 318.3 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 Manual 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 Manual; 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 Manual 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>The Python API bindings for Python 2.x is now marked as being deprecated and will
4796 be removed in a future version. Please upgrade your code to use Python 3.</para>
4797 </listitem>
4798
4799 <listitem><para>The Python API bindings now live in a separate <computeroutput>python</computeroutput>
4800 sub directory and also now support installing via the pip package manager
4801 (e.g. <computeroutput>pip -v install ./vboxapi</computeroutput>). This also allows installing into
4802 Python virtual environments.</para>
4803 </listitem>
4804
4805 <listitem><para>The Windows host installer now uses the sub directory <computeroutput>installer</computeroutput>
4806 instead of <computeroutput>install</computeroutput> for housing the bindings installers. This now matches
4807 the directory layout for the other platforms. Please adapt your scripts if needed.</para>
4808 </listitem>
4809
4810
4811 <listitem><para>Guest process creation requires a new parameter for specifying the current working directory for the new
4812 guest process. This is optional and can be empty.
4813 See <link linkend="IGuestSession__processCreate">IGuestSession::processCreate</link> and
4814 <link linkend="IGuestSession__processCreateEx">IGuestSession::processCreateEx</link> for more information.</para>
4815 </listitem>
4816
4817 <listitem><para>The APIs <link linkend="IGuestSession__fsQueryInfo">IGuestSession::fsQueryInfo</link> and
4818 <link linkend="IGuestSession__fsQueryFreeSpace">IGuestSession::fsQueryFreeSpace</link> are now implemented.
4819 See <link linkend="IGuestSession__fsQueryInfo">IGuestSession::fsQueryInfo</link> and
4820 <link linkend="IGuestSession__fsQueryFreeSpace">IGuestSession::fsQueryFreeSpace</link> for more information.</para>
4821 </listitem>
4822
4823 <listitem><para>The APIs <link linkend="IGuestSession__waitFor">IGuestSession::waitFor</link> and
4824 <link linkend="IProcess__waitFor">IProcess::waitFor</link> are now marked
4825 as being deprecated. Use <link linkend="IGuestSession__waitForArray">IGuestSession::waitForArray</link>
4826 and <link linkend="IProcess__waitForArray">IProcess::waitForArray</link> instead.</para>
4827 </listitem>
4828
4829 <listitem><para>The attribute <link linkend="IGuestSession__mountPoints">IGuestSession::mountPoints</link> has been
4830 added. This requires 7.1 (or newer) Guest Additions to be installed on the guest.</para>
4831 </listitem>
4832
4833 <listitem><para>Review the Main API changes made for the ARM64 CPU architecture <link linkend="vboxarm">here</link>
4834 for incompatible changes to interfaces, methods, and attributes.</para>
4835 </listitem>
4836
4837 </itemizedlist>
4838 </sect1>
4839
4840 <sect1>
4841 <title>Incompatible API changes with version 7.0</title>
4842
4843 <itemizedlist>
4844
4845 <listitem><para>The machine's audio adapter has been moved into the new IAudioSettings interface, which in turn
4846 takes care of of all audio settings of a virtual machine.
4847 See <link linkend="IMachine__audioSettings">IMachine::audioSettings</link> and
4848 <link linkend="IAudioSettings">IAudioSettings</link> for more information.</para>
4849 </listitem>
4850
4851 <listitem><para>The <link linkend="IVirtualBox__openMachine">IVirtualBox::openMachine</link> call now
4852 requires an additional password parameter. If the machine is not encrypted the parameter is ignored.</para>
4853 </listitem>
4854
4855 <listitem><para>When a new VM is being created, the default audio driver will be now
4856 <link linkend="AudioDriverType__Default">AudioDriverType_Default</link>. This driver
4857 type will automatically choose the best audio driver (backend) for the host OS &VBOX_PRODUCT;
4858 currently is running on.</para>
4859 </listitem>
4860
4861 <listitem><para>The host update functionality at IHost::update has been refactored into
4862 <link linkend="IHost__updateHost">IHost::updateHost</link>, which in turn uses the new
4863 <link linkend="IHostUpdateAgent">IHostUpdateAgent</link> interface, derived from the new
4864 <link linkend="IUpdateAgent">IUpdateAgent</link> interface.</para>
4865 </listitem>
4866
4867 <listitem><para><link linkend="IGuestSession__directoryCopyFromGuest">IGuestSession::directoryCopyFromGuest()</link> and
4868 <link linkend="IGuestSession__directoryCopyToGuest">IGuestSession::directoryCopyToGuest()</link> no longer implicitly
4869 copy recursively and follow symbolic links -- for this to continue working, the newly introduced flags
4870 <link linkend="DirectoryCopyFlag__Recursive">DirectoryCopyFlag::Recursive</link> and/or
4871 <link linkend="DirectoryCopyFlag__FollowLinks">DirectoryCopyFlag::FollowLinks</link> have to be used.</para>
4872 </listitem>
4873
4874 <listitem><para>VBoxEventType_Last has been renamed to <link linkend="VBoxEventType__End">VBoxEventType_End</link>
4875 for consistency.</para></listitem>
4876
4877 </itemizedlist>
4878
4879 </sect1>
4880
4881 <sect1>
4882 <title>Incompatible API changes with version 6.1</title>
4883
4884 <itemizedlist>
4885
4886 <listitem><para>Split off the graphics adapter part of
4887 <link linkend="IMachine">IMachine</link> into
4888 <link linkend="IGraphicsAdapter">IGraphicsAdapter</link>.
4889 This moved 5 attributes.</para>
4890 </listitem>
4891
4892 </itemizedlist>
4893
4894 </sect1>
4895
4896 <sect1>
4897 <title>Incompatible API changes with version 6.0</title>
4898
4899 <itemizedlist>
4900
4901 <listitem><para>Video recording APIs were changed as follows:
4902 <itemizedlist>
4903 <listitem><para>All attributes which were living in <link linkend="IMachine">IMachine</link> before
4904 have been moved to an own, dedicated interface named <link linkend="IRecordingSettings">IRecordingSettings</link>.
4905 This new interface can be accessed via the new <link linkend="IMachine__recordingSettings">IMachine::recordingSettings</link>
4906 attribute. This should emphasize that recording is not limited to video capturing as such.</para>
4907 </listitem>
4908
4909 <listitem><para>For further flexibility all specific per-VM-screen settings have been moved to a new interface
4910 called <link linkend="IRecordingScreenSettings">IRecordingScreenSettings</link>. Such settings now exist per configured
4911 VM display and can be retrieved via the <link linkend="IRecordingSettings__screens">IRecordingSettings::screens</link>
4912 attribute or the <link linkend="IRecordingSettings__getScreenSettings">IRecordingSettings::getScreenSettings</link>
4913 method.
4914 <note><para>For now all screen settings will share the same settings, e.g. different settings on a per-screen basis
4915 is not implemented yet.</para></note>
4916 </para>
4917 </listitem>
4918
4919 <listitem><para>The event <computeroutput>IVideoCaptureChangedEvent</computeroutput> was renamed into
4920 <link linkend="IRecordingChangedEvent">IRecordingChangedEvent</link>.</para>
4921 </listitem>
4922
4923 </itemizedlist>
4924 </para></listitem>
4925
4926 <listitem><para>Guest Control APIs were changed as follows:
4927 <itemizedlist>
4928 <listitem><para><link linkend="IGuest__createSession">IGuest::createSession()</link>,
4929 <link linkend="IGuestSession__processCreate">IGuestSession::processCreate()</link>,
4930 <link linkend="IGuestSession__processCreateEx">IGuestSession::processCreateEx()</link>,
4931 <link linkend="IGuestSession__directoryOpen">IGuestSession::directoryOpen()</link> and
4932 <link linkend="IGuestSession__fileOpen">IGuestSession::fileOpen()</link> now will
4933 return the new error code VBOX_E_MAXIMUM_REACHED if the limit for the according object
4934 group has been reached.</para>
4935 </listitem>
4936
4937 <listitem><para>The enumerations FileOpenExFlags, FsObjMoveFlags and DirectoryCopyFlags have
4938 been renamed to <link linkend="FileOpenExFlag">FileOpenExFlag</link>,
4939 <link linkend="FsObjMoveFlag">FsObjMoveFlag</link> and <link linkend="DirectoryCopyFlag">DirectoryCopyFlag</link>
4940 accordingly to match the rest of the API.</para>
4941 </listitem>
4942
4943 <listitem>
4944 <para>The following methods have been implemented:
4945 <computeroutput>IGuestSession::directoryCopyFromGuest()</computeroutput> and
4946 <computeroutput>IGuestSession::directoryCopyToGuest()</computeroutput>.
4947 </para>
4948
4949 <para>The following attributes have been implemented:
4950 <computeroutput>IGuestFsObjInfo::accessTime</computeroutput>,
4951 <computeroutput>IGuestFsObjInfo::birthTime</computeroutput>,
4952 <computeroutput>IGuestFsObjInfo::changeTime</computeroutput> and
4953 <computeroutput>IGuestFsObjInfo::modificationTime</computeroutput>.
4954 </para>
4955
4956 </listitem>
4957 </itemizedlist>
4958 </para></listitem>
4959
4960 <listitem><para>The webservice version of the <link linkend="ISharedFolder">ISharedFolder</link>
4961 interface was changed from a struct to a managed object. This causes incompatibilities on the
4962 protocol level as the shared folder attributes are not returned in the responses of
4963 <link linkend="IVirtualBox__sharedFolders">IVirtualBox::getSharedFolders</link> and
4964 <link linkend="IMachine__sharedFolders">IMachine::getSharedFolders</link> anymore. They
4965 return object UUIDs instead which need be wrapped by stub objects. The change is not visible when
4966 using the appropriate client bindings from the most recent VirtualBox SDK.
4967 </para></listitem>
4968
4969 </itemizedlist>
4970
4971 </sect1>
4972
4973 <sect1>
4974 <title>Incompatible API changes with version 5.x</title>
4975
4976 <itemizedlist>
4977 <listitem><para>ProcessCreateFlag::NoProfile has been renamed to
4978 <link linkend="ProcessCreateFlag__Profile">ProcessCreateFlag::Profile</link>,
4979 and the semantics have also been changed: ProcessCreateFlag::NoProfile
4980 explicitly <emphasis role="bold">did not</emphasis> utilize the guest user's profile data
4981 whereas <link linkend="ProcessCreateFlag__Profile">ProcessCreateFlag::Profile</link>
4982 explicitly <emphasis role="bold">does</emphasis> utilize the guest
4983 user’s profile data.</para>
4984 </listitem>
4985 </itemizedlist>
4986
4987 </sect1>
4988
4989 <sect1>
4990 <title>Incompatible API changes with version 5.1.28</title>
4991
4992 <itemizedlist>
4993 <listitem><para>The Host-Guest Communication Manager (HGCM) guest driver
4994 interfaces were renamed:
4995 <itemizedlist>
4996 <listitem><para>VbglHGCMConnect() was renamed to VbglR0HGCMConnect()
4997 </para></listitem>
4998 <listitem><para>VbglHGCMDisconnect() was renamed to VbglR0HGCMDisconnect()
4999 </para></listitem>
5000 <listitem><para>VbglHGCMCall() was renamed to VbglR0HGCMCall()
5001 </para></listitem>
5002 </itemizedlist>
5003 </para>
5004 </listitem>
5005
5006 <listitem><para>The Host-Guest Communication Manager (HGCM) guest
5007 application interface IOCTLs were renamed:
5008 <itemizedlist>
5009 <listitem><para>VBOXGUEST_IOCTL_HGCM_CONNECT was renamed to
5010 VBGL_IOCTL_HGCM_CONNECT
5011 </para></listitem>
5012 <listitem><para>VBOXGUEST_IOCTL_HGCM_DISCONNECT was renamed to
5013 VBGL_IOCTL_HGCM_DISCONNECT
5014 </para></listitem>
5015 <listitem><para>VBOXGUEST_IOCTL_HGCM_CALL was renamed to
5016 VBGL_IOCTL_HGCM_CALL
5017 </para></listitem>
5018 </itemizedlist>
5019 </para>
5020 </listitem>
5021
5022 </itemizedlist>
5023
5024 </sect1>
5025
5026
5027 <sect1>
5028 <title>Incompatible API changes with version 5.0</title>
5029
5030 <itemizedlist>
5031 <listitem>
5032 <para>The methods for saving state, adopting a saved state file,
5033 discarding a saved state, taking a snapshot, restoring
5034 a snapshot and deleting a snapshot have been moved from
5035 <computeroutput>IConsole</computeroutput> to
5036 <computeroutput>IMachine</computeroutput>. This straightens out the
5037 logical placement of methods and was necessary to resolve a
5038 long-standing issue, preventing 32-bit API clients from invoking
5039 those operations in the case where no VM is running.
5040 <itemizedlist>
5041 <listitem><para><link linkend="IMachine__saveState">IMachine::saveState()</link>
5042 replaces
5043 <computeroutput>IConsole::saveState()</computeroutput></para>
5044 </listitem>
5045 <listitem>
5046 <para><link linkend="IMachine__adoptSavedState">IMachine::adoptSavedState()</link>
5047 replaces
5048 <computeroutput>IConsole::adoptSavedState()</computeroutput></para>
5049 </listitem>
5050 <listitem>
5051 <para><link linkend="IMachine__discardSavedState">IMachine::discardSavedState()</link>
5052 replaces
5053 <computeroutput>IConsole::discardSavedState()</computeroutput></para>
5054 </listitem>
5055 <listitem>
5056 <para><link linkend="IMachine__takeSnapshot">IMachine::takeSnapshot()</link>
5057 replaces
5058 <computeroutput>IConsole::takeSnapshot()</computeroutput></para>
5059 </listitem>
5060 <listitem>
5061 <para><link linkend="IMachine__deleteSnapshot">IMachine::deleteSnapshot()</link>
5062 replaces
5063 <computeroutput>IConsole::deleteSnapshot()</computeroutput></para>
5064 </listitem>
5065 <listitem>
5066 <para><link linkend="IMachine__deleteSnapshotAndAllChildren">IMachine::deleteSnapshotAndAllChildren()</link>
5067 replaces
5068 <computeroutput>IConsole::deleteSnapshotAndAllChildren()</computeroutput></para>
5069 </listitem>
5070 <listitem>
5071 <para><link linkend="IMachine__deleteSnapshotRange">IMachine::deleteSnapshotRange()</link>
5072 replaces
5073 <computeroutput>IConsole::deleteSnapshotRange()</computeroutput></para>
5074 </listitem>
5075 <listitem>
5076 <para><link linkend="IMachine__restoreSnapshot">IMachine::restoreSnapshot()</link>
5077 replaces
5078 <computeroutput>IConsole::restoreSnapshot()</computeroutput></para>
5079 </listitem>
5080 </itemizedlist>
5081 Small adjustments to the parameter lists have been made to reduce
5082 the number of API calls when taking online snapshots (no longer
5083 needs explicit pausing), and taking a snapshot also returns now
5084 the snapshot id (useful for finding the right snapshot if there
5085 are non-unique snapshot names).</para>
5086 </listitem>
5087
5088 <listitem>
5089 <para>Two new machine states have been introduced to allow proper
5090 distinction between saving state and taking a snapshot.
5091 <link linkend="MachineState__Saving">MachineState::Saving</link>
5092 now is used exclusively while the VM's state is being saved, without
5093 any overlaps with snapshot functionality. The new state
5094 <link linkend="MachineState__Snapshotting">MachineState::Snapshotting</link>
5095 is used when an offline snapshot is taken and likewise the new state
5096 <link linkend="MachineState__OnlineSnapshotting">MachineState::OnlineSnapshotting</link>
5097 is used when an online snapshot is taken.</para>
5098 </listitem>
5099
5100 <listitem>
5101 <para>A new event has been introduced, which signals when a snapshot
5102 has been restored:
5103 <link linkend="ISnapshotRestoredEvent">ISnapshotRestoredEvent</link>.
5104 Previously the event
5105 <link linkend="ISnapshotDeletedEvent">ISnapshotDeletedEvent</link>
5106 was signalled, which isn't logical (but could be distinguished from
5107 actual deletion by the fact that the snapshot was still
5108 there).</para>
5109 </listitem>
5110
5111 <listitem>
5112 <para>The method
5113 <link linkend="IVirtualBox__createMedium">IVirtualBox::createMedium()</link>
5114 replaces
5115 <computeroutput>VirtualBox::createHardDisk()</computeroutput>.
5116 Adjusting existing code needs adding two parameters with
5117 value <computeroutput>AccessMode_ReadWrite</computeroutput>
5118 and <computeroutput>DeviceType_HardDisk</computeroutput>
5119 respectively. The new method supports creating floppy and
5120 DVD images, and (less obviously) further API functionality
5121 such as cloning floppy images.</para>
5122 </listitem>
5123
5124 <listitem>
5125 <para>The method
5126 <link linkend="IMachine__getStorageControllerByInstance">IMachine::getStorageControllerByInstance()</link>
5127 now has an additional parameter (first parameter), for specifying the
5128 storage bus which the storage controller must be using. The method
5129 was not useful before, as the instance numbers are only unique for a
5130 specfic storage bus.</para>
5131 </listitem>
5132
5133 <listitem>
5134 <para>The attribute
5135 <computeroutput>IMachine::sessionType</computeroutput> has been
5136 renamed to
5137 <link linkend="IMachine__sessionName">IMachine::sessionName()</link>.
5138 This cleans up the confusing terminology (as the session type is
5139 something different).</para>
5140 </listitem>
5141
5142 <listitem>
5143 <para>The attribute
5144 <computeroutput>IMachine::guestPropertyNotificationPatterns</computeroutput>
5145 has been removed. In practice it was not usable because it is too
5146 global and didn't distinguish between API clients.</para>
5147 </listitem>
5148
5149 <listitem><para>Drag and drop APIs were changed as follows:<itemizedlist>
5150
5151 <listitem>
5152 <para>Methods for providing host to guest drag and drop
5153 functionality, such as
5154 <computeroutput>IGuest::dragHGEnter</computeroutput>,
5155 <computeroutput>IGuest::dragHGMove()</computeroutput>,
5156 <computeroutput>IGuest::dragHGLeave()</computeroutput>,
5157 <computeroutput>IGuest::dragHGDrop()</computeroutput> and
5158 <computeroutput>IGuest::dragHGPutData()</computeroutput>,
5159 have been moved to an abstract base class called
5160 <link linkend="IDnDTarget">IDnDTarget</link>.
5161 VirtualBox implements this base class in the
5162 <link linkend="IGuestDnDTarget">IGuestDnDTarget</link>
5163 interface. The implementation can be used by using the
5164 <link linkend="IGuest__dnDTarget">IGuest::dnDTarget()</link>
5165 method.</para>
5166 <para>Methods for providing guest to host drag and drop
5167 functionality, such as
5168 <computeroutput>IGuest::dragGHPending()</computeroutput>,
5169 <computeroutput>IGuest::dragGHDropped()</computeroutput> and
5170 <computeroutput>IGuest::dragGHGetData()</computeroutput>,
5171 have been moved to an abstract base class called
5172 <link linkend="IDnDSource">IDnDSource</link>.
5173 VirtualBox implements this base class in the
5174 <link linkend="IGuestDnDSource">IGuestDnDSource</link>
5175 interface. The implementation can be used by using the
5176 <link linkend="IGuest__dnDSource">IGuest::dnDSource()</link>
5177 method.</para>
5178 </listitem>
5179
5180 <listitem>
5181 <para>The <computeroutput>DragAndDropAction</computeroutput>
5182 enumeration has been renamed to
5183 <link linkend="DnDAction">DnDAction</link>.</para>
5184 </listitem>
5185
5186 <listitem>
5187 <para>The <computeroutput>DragAndDropMode</computeroutput>
5188 enumeration has been renamed to
5189 <link linkend="DnDMode">DnDMode</link>.</para>
5190 </listitem>
5191
5192 <listitem>
5193 <para>The attribute
5194 <computeroutput>IMachine::dragAndDropMode</computeroutput>
5195 has been renamed to
5196 <link linkend="IMachine__dnDMode">IMachine::dnDMode()</link>.</para>
5197 </listitem>
5198
5199 <listitem>
5200 <para>The event
5201 <computeroutput>IDragAndDropModeChangedEvent</computeroutput>
5202 has been renamed to
5203 <link linkend="IDnDModeChangedEvent">IDnDModeChangedEvent</link>.</para>
5204 </listitem>
5205
5206 </itemizedlist></para>
5207 </listitem>
5208
5209 <listitem><para>IDisplay and IFramebuffer interfaces were changed to
5210 allow IFramebuffer object to reside in a separate front-end
5211 process:<itemizedlist>
5212
5213 <listitem><para>
5214 IDisplay::ResizeCompleted() has been removed, because the
5215 IFramebuffer object does not provide the screen memory anymore.
5216 </para></listitem>
5217
5218 <listitem><para>
5219 IDisplay::SetFramebuffer() has been replaced with
5220 IDisplay::AttachFramebuffer() and IDisplay::DetachFramebuffer().
5221 </para></listitem>
5222
5223 <listitem><para>
5224 IDisplay::GetFramebuffer() has been replaced with
5225 IDisplay::QueryFramebuffer().
5226 </para></listitem>
5227
5228 <listitem><para>
5229 IDisplay::GetScreenResolution() has a new output parameter
5230 <computeroutput>guestMonitorStatus</computeroutput>
5231 which tells whether the monitor is enabled in the guest.
5232 </para></listitem>
5233
5234 <listitem><para>
5235 IDisplay::TakeScreenShot() and IDisplay::TakeScreenShotToArray()
5236 have a new parameter
5237 <computeroutput>bitmapFormat</computeroutput>. As a consequence of
5238 this, IDisplay::TakeScreenShotPNGToArray() has been removed.
5239 </para></listitem>
5240
5241 <listitem><para>
5242 IFramebuffer::RequestResize() has been replaced with
5243 IFramebuffer::NotifyChange().
5244 </para></listitem>
5245
5246 <listitem><para>
5247 IFramebuffer::NotifyUpdateImage() added to support IFramebuffer
5248 objects in a different process.
5249 </para></listitem>
5250
5251 <listitem><para>
5252 IFramebuffer::Lock(), IFramebuffer::Unlock(),
5253 IFramebuffer::Address(), IFramebuffer::UsesGuestVRAM() have been
5254 removed because the IFramebuffer object does not provide the screen
5255 memory anymore.
5256 </para></listitem>
5257
5258 </itemizedlist></para>
5259 </listitem>
5260
5261 <listitem><para>IGuestSession, IGuestFile and IGuestProcess interfaces
5262 were changed as follows:
5263 <itemizedlist>
5264 <listitem>
5265 <para>Replaced IGuestSession::directoryQueryInfo and
5266 IGuestSession::fileQueryInfo with a new
5267 <link linkend="IGuestSession__fsObjQueryInfo">IGuestSession::fsObjQueryInfo</link>
5268 method that works on any type of file system object.</para>
5269 </listitem>
5270 <listitem>
5271 <para>Replaced IGuestSession::fileRemove,
5272 IGuestSession::symlinkRemoveDirectory and
5273 IGuestSession::symlinkRemoveFile with a new
5274 <link linkend="IGuestSession__fsObjRemove">IGuestSession::fsObjRemove</link>
5275 method that works on any type of file system object except
5276 directories. (fileRemove also worked on any type of object
5277 too, though that was not the intent of the method.)</para>
5278 </listitem>
5279 <listitem>
5280 <para>Replaced IGuestSession::directoryRename and
5281 IGuestSession::directoryRename with a new
5282 <link linkend="IGuestSession__fsObjRename">IGuestSession::fsObjRename</link>
5283 method that works on any type of file system object.
5284 (directoryRename and fileRename may already have worked for
5285 any kind of object, but that was never the intent of the
5286 methods.)</para>
5287 </listitem>
5288 <listitem>
5289 <para>Replaced the unimplemented IGuestSession::directorySetACL
5290 and IGuestSession::fileSetACL with a new
5291 <link linkend="IGuestSession__fsObjSetACL">IGuestSession::fsObjSetACL</link>
5292 method that works on all type of file system object. Also
5293 added a UNIX-style mode parameter as an alternative to the
5294 ACL.</para>
5295 </listitem>
5296 <listitem>
5297 <para>Replaced IGuestSession::fileRemove,
5298 IGuestSession::symlinkRemoveDirectory and
5299 IGuestSession::symlinkRemoveFile with a new
5300 <link linkend="IGuestSession__fsObjRemove">IGuestSession::fsObjRemove</link>
5301 method that works on any type of file system object except
5302 directories (fileRemove also worked on any type of object,
5303 though that was not the intent of the method.)</para>
5304 </listitem>
5305 <listitem>
5306 <para>Renamed IGuestSession::copyTo to
5307 <link linkend="IGuestSession__fileCopyToGuest">IGuestSession::fileCopyToGuest</link>.</para>
5308 </listitem>
5309 <listitem>
5310 <para>Renamed IGuestSession::copyFrom to
5311 <link linkend="IGuestSession__fileCopyFromGuest">IGuestSession::fileCopyFromGuest</link>.</para>
5312 </listitem>
5313 <listitem>
5314 <para>Renamed the CopyFileFlag enum to
5315 <link linkend="FileCopyFlag">FileCopyFlag</link>.</para>
5316 </listitem>
5317 <listitem>
5318 <para>Renamed the IGuestSession::environment attribute to
5319 <link linkend="IGuestSession__environmentChanges">IGuestSession::environmentChanges</link>
5320 to better reflect what it does.</para>
5321 </listitem>
5322 <listitem>
5323 <para>Changed the
5324 <link linkend="IProcess__environment">IGuestProcess::environment</link>
5325 to a stub returning E_NOTIMPL since it wasn't doing what was
5326 advertised (returned changes, not the actual environment).</para>
5327 </listitem>
5328 <listitem>
5329 <para>Renamed IGuestSession::environmentSet to
5330 <link linkend="IGuestSession__environmentScheduleSet">IGuestSession::environmentScheduleSet</link>
5331 to better reflect what it does.</para>
5332 </listitem>
5333 <listitem>
5334 <para>Renamed IGuestSession::environmentUnset to
5335 <link linkend="IGuestSession__environmentScheduleUnset">IGuestSession::environmentScheduleUnset</link>
5336 to better reflect what it does.</para>
5337 </listitem>
5338 <listitem>
5339 <para>Removed IGuestSession::environmentGet it was only getting
5340 changes while giving the impression it was actual environment
5341 variables, and it did not represent scheduled unset
5342 operations.</para>
5343 </listitem>
5344 <listitem>
5345 <para>Removed IGuestSession::environmentClear as it duplicates
5346 assigning an empty array to the
5347 <link linkend="IGuestSession__environmentChanges">IGuestSession::environmentChanges</link>
5348 (formerly known as IGuestSession::environment).</para>
5349 </listitem>
5350 <listitem>
5351 <para>Changed the
5352 <link linkend="IGuestSession__processCreate">IGuestSession::processCreate</link>
5353 and
5354 <link linkend="IGuestSession__processCreateEx">IGuestSession::processCreateEx</link>
5355 methods to accept arguments starting with argument zero (argv[0])
5356 instead of argument one (argv[1]). (Not yet implemented on the
5357 guest additions side, so argv[0] will probably be ignored for a
5358 short while.)</para>
5359 </listitem>
5360
5361 <listitem>
5362 <para>Added a followSymlink parameter to the following methods:
5363 <itemizedlist>
5364 <listitem><para><link linkend="IGuestSession__directoryExists">IGuestSession::directoryExists</link></para></listitem>
5365 <listitem><para><link linkend="IGuestSession__fileExists">IGuestSession::fileExists</link></para></listitem>
5366 <listitem><para><link linkend="IGuestSession__fileQuerySize">IGuestSession::fileQuerySize</link></para></listitem>
5367 </itemizedlist></para>
5368 </listitem>
5369 <listitem>
5370 <para>The parameters to the
5371 <link linkend="IGuestSession__fileOpen">IGuestSession::fileOpen</link>
5372 and
5373 <link linkend="IGuestSession__fileOpenEx">IGuestSession::fileOpenEx</link>
5374 methods were altered:<itemizedlist>
5375 <listitem><para>The openMode string parameter was replaced by
5376 the enum
5377 <link linkend="FileAccessMode">FileAccessMode</link>
5378 and renamed to accessMode.</para></listitem>
5379 <listitem><para>The disposition string parameter was replaced
5380 by the enum
5381 <link linkend="FileOpenAction">FileOpenAction</link>
5382 and renamed to openAction.</para></listitem>
5383 <listitem><para>The unimplemented sharingMode string parameter
5384 was replaced by the enum
5385 <link linkend="FileSharingMode">FileSharingMode</link>
5386 (fileOpenEx only).</para></listitem>
5387 <listitem><para>Added a flags parameter taking a list of
5388 <link linkend="FileOpenExFlag">FileOpenExFlag</link> values
5389 (fileOpenEx only).</para></listitem>
5390 <listitem><para>Removed the offset parameter (fileOpenEx
5391 only).</para></listitem>
5392 </itemizedlist></para>
5393 </listitem>
5394
5395 <listitem>
5396 <para><link linkend="IFile__seek">IGuestFile::seek</link> now
5397 returns the new offset.</para>
5398 </listitem>
5399 <listitem>
5400 <para>Renamed the FileSeekType enum used by
5401 <link linkend="IFile__seek">IGuestFile::seek</link>
5402 to <link linkend="FileSeekOrigin">FileSeekOrigin</link> and
5403 added the missing End value and renaming the Set to
5404 Begin.</para>
5405 </listitem>
5406 <listitem>
5407 <para>Extended the unimplemented
5408 <link linkend="IFile__setACL">IGuestFile::setACL</link>
5409 method with a UNIX-style mode parameter as an alternative to
5410 the ACL.</para>
5411 </listitem>
5412 <listitem>
5413 <para>Renamed the IFile::openMode attribute to
5414 <link linkend="IFile__accessMode">IFile::accessMode</link>
5415 and change the type from string to
5416 <link linkend="FileAccessMode">FileAccessMode</link> to reflect
5417 the changes to the fileOpen methods.</para>
5418 </listitem>
5419 <listitem>
5420 <para>Renamed the IGuestFile::disposition attribute to
5421 <link linkend="IFile__openAction">IFile::openAction</link> and
5422 change the type from string to
5423 <link linkend="FileOpenAction">FileOpenAction</link> to reflect
5424 the changes to the fileOpen methods.</para>
5425 </listitem>
5426
5427 <!-- Non-incompatible things worth mentioning (stubbed methods/attrs aren't worth it). -->
5428 <listitem>
5429 <para>Added
5430 <link linkend="IGuestSession__pathStyle">IGuestSession::pathStyle</link>
5431 attribute.</para>
5432 </listitem>
5433 <listitem>
5434 <para>Added
5435 <link linkend="IGuestSession__fsObjExists">IGuestSession::fsObjExists</link>
5436 attribute.</para>
5437 </listitem>
5438
5439 </itemizedlist>
5440 </para>
5441 </listitem>
5442
5443 <listitem><para>
5444 IConsole::GetDeviceActivity() returns information about multiple
5445 devices.
5446 </para></listitem>
5447
5448 <listitem><para>
5449 IMachine::ReadSavedThumbnailToArray() has a new parameter
5450 <computeroutput>bitmapFormat</computeroutput>. As a consequence of
5451 this, IMachine::ReadSavedThumbnailPNGToArray() has been removed.
5452 </para></listitem>
5453
5454 <listitem><para>
5455 IMachine::QuerySavedScreenshotPNGSize() has been renamed to
5456 IMachine::QuerySavedScreenshotInfo() which also returns
5457 an array of available screenshot formats.
5458 </para></listitem>
5459
5460 <listitem><para>
5461 IMachine::ReadSavedScreenshotPNGToArray() has been renamed to
5462 IMachine::ReadSavedScreenshotToArray() which has a new parameter
5463 <computeroutput>bitmapFormat</computeroutput>.
5464 </para></listitem>
5465
5466 <listitem><para>
5467 IMachine::QuerySavedThumbnailSize() has been removed.
5468 </para></listitem>
5469
5470 <listitem>
5471 <para>The method
5472 <link linkend="IWebsessionManager__getSessionObject">IWebsessionManager::getSessionObject()</link>
5473 now returns a new <link linkend="ISession">ISession</link> instance
5474 for every invocation. This puts the behavior in line with other
5475 binding styles, which never forced the equivalent of establishing
5476 another connection and logging in again to get another
5477 instance.</para>
5478 </listitem>
5479 </itemizedlist>
5480 </sect1>
5481
5482 <sect1>
5483 <title>Incompatible API changes with version 4.3</title>
5484
5485 <itemizedlist>
5486 <listitem>
5487 <para>The explicit medium locking methods
5488 <link linkend="IMedium__lockRead">IMedium::lockRead()</link>
5489 and <link linkend="IMedium__lockWrite">IMedium::lockWrite()</link>
5490 have been redesigned. They return a lock token object reference
5491 now, and calling the
5492 <link linkend="IToken__abandon">IToken::abandon()</link> method (or
5493 letting the reference count to this object drop to 0) will unlock
5494 it. This eliminates the rather common problem that an API client
5495 crash left behind locks, and also improves the safety (API clients
5496 can't release locks they didn't obtain).</para>
5497 </listitem>
5498
5499 <listitem>
5500 <para>The parameter list of
5501 <link linkend="IAppliance__write">IAppliance::write()</link>
5502 has been changed slightly, to allow multiple flags to be
5503 passed.</para>
5504 </listitem>
5505
5506 <listitem>
5507 <para><computeroutput>IMachine::delete</computeroutput>
5508 has been renamed to
5509 <link linkend="IMachine__deleteConfig">IMachine::deleteConfig()</link>,
5510 to improve API client binding compatibility.</para>
5511 </listitem>
5512
5513 <listitem>
5514 <para><computeroutput>IMachine::export</computeroutput>
5515 has been renamed to
5516 <link linkend="IMachine__exportTo">IMachine::exportTo()</link>,
5517 to improve API client binding compatibility.</para>
5518 </listitem>
5519
5520 <listitem>
5521 <para>For
5522 <link linkend="IMachine__launchVMProcess">IMachine::launchVMProcess()</link>
5523 the meaning of the <computeroutput>type</computeroutput> parameter
5524 has changed slightly. Empty string now means that the per-VM or
5525 global default front-end is launched. Most callers of this method
5526 should use the empty string now, unless they really want to override
5527 the default and launch a particular front-end.</para>
5528 </listitem>
5529
5530 <listitem>
5531 <para>Medium management APIs were changed as follows:<itemizedlist>
5532
5533 <listitem>
5534 <para>The type of attribute
5535 <link linkend="IMedium__variant">IMedium::variant()</link>
5536 changed from <computeroutput>unsigned long</computeroutput>
5537 to <computeroutput>safe-array MediumVariant</computeroutput>.
5538 It is an array of flags instead of a set of flags which were
5539 stored inside one variable.
5540 </para>
5541 </listitem>
5542
5543 <listitem>
5544 <para>The parameter list for
5545 <link linkend="IMedium__cloneTo">IMedium::cloneTo()</link>
5546 was modified. The type of parameter variant was changed from
5547 unsigned long to safe-array MediumVariant.
5548 </para>
5549 </listitem>
5550
5551 <listitem>
5552 <para>The parameter list for
5553 <link linkend="IMedium__createBaseStorage">IMedium::createBaseStorage()</link>
5554 was modified. The type of parameter variant was changed from
5555 unsigned long to safe-array MediumVariant.
5556 </para>
5557 </listitem>
5558
5559 <listitem>
5560 <para>The parameter list for
5561 <link linkend="IMedium__createDiffStorage">IMedium::createDiffStorage()</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__cloneToBase">IMedium::cloneToBase()</link>
5570 was modified. The type of parameter variant was changed from
5571 unsigned long to safe-array MediumVariant.
5572 </para>
5573 </listitem>
5574 </itemizedlist></para>
5575 </listitem>
5576
5577 <listitem>
5578 <para>The type of attribute
5579 <link linkend="IMediumFormat__capabilities">IMediumFormat::capabilities()</link>
5580 changed from <computeroutput>unsigned long</computeroutput> to
5581 <computeroutput>safe-array MediumFormatCapabilities</computeroutput>.
5582 It is an array of flags instead of a set of flags which were stored
5583 inside one variable.
5584 </para>
5585 </listitem>
5586
5587 <listitem>
5588 <para>The attribute
5589 <link linkend="IMedium__logicalSize">IMedium::logicalSize()</link>
5590 now returns the logical size of exactly this medium object (whether
5591 it is a base or diff image). The old behavior was no longer
5592 acceptable, as each image can have a different capacity.</para>
5593 </listitem>
5594
5595 <listitem>
5596 <para>Guest control APIs - such as
5597 <link linkend="IGuest">IGuest</link>,
5598 <link linkend="IGuestSession">IGuestSession</link>,
5599 <link linkend="IGuestProcess">IGuestProcess</link> and so on - now
5600 emit own events to provide clients much finer control and the ability
5601 to write own front-ends for guest operations. The event
5602 <link linkend="IGuestSessionEvent">IGuestSessionEvent</link> acts as
5603 an abstract base class for all guest control events. Certain guest
5604 events contain a
5605 <link linkend="IVirtualBoxErrorInfo">IVirtualBoxErrorInfo</link>
5606 member to provide more information in case of an error happened on
5607 the guest side.</para>
5608 </listitem>
5609
5610 <listitem>
5611 <para>Guest control sessions on the guest started by
5612 <link linkend="IGuest__createSession">IGuest::createSession()</link>
5613 now are dedicated guest processes to provide more safety and
5614 performance for certain operations. Also, the
5615 <link linkend="IGuest__createSession">IGuest::createSession()</link>
5616 call does not wait for the guest session being created anymore due
5617 to the dedicated guest session processes just mentioned. This also
5618 will enable webservice clients to handle guest session creation
5619 more gracefully. To wait for a guest session being started, use the
5620 newly added attribute
5621 <link linkend="IGuestSession__status">IGuestSession::status()</link>
5622 to query the current guest session status.</para>
5623 </listitem>
5624
5625 <listitem>
5626 <para>The <link linkend="IGuestFile">IGuestFile</link>
5627 APIs are now implemented to provide native guest file access from
5628 the host.</para>
5629 </listitem>
5630
5631 <listitem>
5632 <para>The parameter list for
5633 <link linkend="IGuest__updateGuestAdditions">IMedium::updateGuestAdditions()</link>
5634 was modified. It now supports specifying optional command line
5635 arguments for the Guest Additions installer performing the actual
5636 update on the guest.
5637 </para>
5638 </listitem>
5639
5640 <listitem>
5641 <para>A new event
5642 <link linkend="IGuestUserStateChangedEvent">IGuestUserStateChangedEvent</link>
5643 was introduced to provide guest user status updates to the host via
5644 event listeners. To use this event there needs to be at least the 4.3
5645 Guest Additions installed on the guest. At the moment only the states
5646 "Idle" and "InUse" of the
5647 <link linkend="GuestUserState">GuestUserState</link> enumeration arei
5648 supported on Windows guests, starting at Windows 2000 SP2.</para>
5649 </listitem>
5650
5651 <listitem>
5652 <para>
5653 The attribute
5654 <link linkend="IGuestSession__protocolVersion">IGuestSession::protocolVersion</link>
5655 was added to provide a convenient way to lookup the guest session's
5656 protocol version it uses to communicate with the installed Guest
5657 Additions on the guest. Older Guest Additions will set the protocol
5658 version to 1, whereas Guest Additions 4.3 will set the protocol
5659 version to 2. This might change in the future as new features
5660 arise.</para>
5661 </listitem>
5662
5663 <listitem>
5664 <para><computeroutput>IDisplay::getScreenResolution</computeroutput>
5665 has been extended to return the display position in the guest.</para>
5666 </listitem>
5667
5668 <listitem>
5669 <para>
5670 The <link linkend="IUSBController">IUSBController</link>
5671 class is not a singleton of
5672 <link linkend="IMachine">IMachine</link> anymore but
5673 <link linkend="IMachine">IMachine</link> contains a list of USB
5674 controllers present in the VM. The USB device filter handling was
5675 moved to
5676 <link linkend="IUSBDeviceFilters">IUSBDeviceFilters</link>.
5677 </para>
5678 </listitem>
5679 </itemizedlist>
5680 </sect1>
5681
5682 <sect1>
5683 <title>Incompatible API changes with version 4.2</title>
5684
5685 <itemizedlist>
5686 <listitem>
5687 <para>Guest control APIs for executing guest processes, working with
5688 guest files or directories have been moved to the newly introduced
5689 <link linkend="IGuestSession">IGuestSession</link> interface which
5690 can be created by calling
5691 <link linkend="IGuest__createSession">IGuest::createSession()</link>.</para>
5692
5693 <para>A guest session will act as a
5694 guest user's impersonation so that the guest credentials only have to
5695 be provided when creating a new guest session. There can be up to 32
5696 guest sessions at once per VM, each session serving up to 2048 guest
5697 processes running or files opened.</para>
5698
5699 <para>Instead of working with process or directory handles before
5700 version 4.2, there now are the dedicated interfaces
5701 <link linkend="IGuestProcess">IGuestProcess</link>,
5702 <link linkend="IGuestDirectory">IGuestDirectory</link> and
5703 <link linkend="IGuestFile">IGuestFile</link>. To retrieve more
5704 information of a file system object the new interface
5705 <link linkend="IGuestFsObjInfo">IGuestFsObjInfo</link> has been
5706 introduced.</para>
5707
5708 <para>Even though the guest control API was changed it is backwards
5709 compatible so that it can be used with older installed Guest
5710 Additions. However, to use upcoming features like process termination
5711 or waiting for input / output new Guest Additions must be installed
5712 when these features got implemented.</para>
5713
5714 <para>The following limitations apply:
5715 <itemizedlist>
5716 <listitem><para>The <link linkend="IGuestFile">IGuestFile</link>
5717 interface is not fully implemented yet.</para>
5718 </listitem>
5719 <listitem><para>The symbolic link APIs
5720 <link linkend="IGuestSession__symlinkCreate">IGuestSession::symlinkCreate()</link>,
5721 <link linkend="IGuestSession__symlinkExists">IGuestSession::symlinkExists()</link>,
5722 <link linkend="IGuestSession__symlinkRead">IGuestSession::symlinkRead()</link>,
5723 IGuestSession::symlinkRemoveDirectory() and
5724 IGuestSession::symlinkRemoveFile() are not
5725 implemented yet.</para>
5726 </listitem>
5727 <listitem><para>The directory APIs
5728 <link linkend="IGuestSession__directoryRemove">IGuestSession::directoryRemove()</link>,
5729 <link linkend="IGuestSession__directoryRemoveRecursive">IGuestSession::directoryRemoveRecursive()</link>,
5730 IGuestSession::directoryRename() and
5731 IGuestSession::directorySetACL() are not
5732 implemented yet.</para>
5733 </listitem>
5734 <listitem><para>The temporary file creation API
5735 <link linkend="IGuestSession__fileCreateTemp">IGuestSession::fileCreateTemp()</link>
5736 is not implemented yet.</para>
5737 </listitem>
5738 <listitem><para>Guest process termination via
5739 <link linkend="IProcess__terminate">IProcess::terminate()</link>
5740 is not implemented yet.</para>
5741 </listitem>
5742 <listitem><para>Waiting for guest process output via
5743 <link linkend="ProcessWaitForFlag__StdOut">ProcessWaitForFlag::StdOut</link>
5744 and
5745 <link linkend="ProcessWaitForFlag__StdErr">ProcessWaitForFlag::StdErr</link>
5746 is not implemented yet.</para>
5747 <para>To wait for process output,
5748 <link linkend="IProcess__read">IProcess::read()</link> with
5749 appropriate flags still can be used to periodically check for
5750 new output data to arrive. Note that
5751 <link linkend="ProcessCreateFlag__WaitForStdOut">ProcessCreateFlag::WaitForStdOut</link>
5752 and / or
5753 <link linkend="ProcessCreateFlag__WaitForStdErr">ProcessCreateFlag::WaitForStdErr</link>
5754 need to be specified when creating a guest process via
5755 <link linkend="IGuestSession__processCreate">IGuestSession::processCreate()</link>
5756 or
5757 <link linkend="IGuestSession__processCreateEx">IGuestSession::processCreateEx()</link>.</para>
5758 </listitem>
5759 <listitem>
5760 <para>ACL (Access Control List) handling in general is not
5761 implemented yet.</para>
5762 </listitem>
5763 </itemizedlist>
5764 </para>
5765 </listitem>
5766
5767 <listitem>
5768 <para>The <link linkend="LockType">LockType</link>
5769 enumeration now has an additional value
5770 <computeroutput>VM</computeroutput> which tells
5771 <link linkend="IMachine__lockMachine">IMachine::lockMachine()</link>
5772 to create a full-blown object structure for running a VM. This was
5773 the previous behavior with <computeroutput>Write</computeroutput>,
5774 which now only creates the minimal object structure to save time and
5775 resources (at the moment the Console object is still created, but all
5776 sub-objects such as Display, Keyboard, Mouse, Guest are not.</para>
5777 </listitem>
5778
5779 <listitem>
5780 <para>Machines can be put in groups (actually an array of groups).
5781 The primary group affects the default placement of files belonging
5782 to a VM.
5783 <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
5784 and
5785 <link linkend="IVirtualBox__composeMachineFilename">IVirtualBox::composeMachineFilename()</link>
5786 have been adjusted accordingly, the former taking an array of groups
5787 as an additional parameter and the latter taking a group as an
5788 additional parameter. The create option handling has been changed for
5789 those two methods, too.</para>
5790 </listitem>
5791
5792 <listitem>
5793 <para>The method IVirtualBox::findMedium() has been removed, since
5794 it provides a subset of the functionality of
5795 <link linkend="IVirtualBox__openMedium">IVirtualBox::openMedium()</link>.</para>
5796 </listitem>
5797
5798 <listitem>
5799 <para>The use of acronyms in API enumeration, interface, attribute
5800 and method names has been made much more consistent, previously they
5801 sometimes were lowercase and sometimes mixed case. They are now
5802 consistently all caps:<table>
5803 <title>Renamed identifiers in VirtualBox 4.2</title>
5804
5805 <tgroup cols="2" style="verywide">
5806 <tbody>
5807 <row>
5808 <entry><emphasis role="bold">Old name</emphasis></entry>
5809
5810 <entry><emphasis role="bold">New name</emphasis></entry>
5811 </row>
5812 <row>
5813 <entry>PointingHidType</entry>
5814 <entry><link linkend="PointingHIDType">PointingHIDType</link></entry>
5815 </row>
5816 <row>
5817 <entry>KeyboardHidType</entry>
5818 <entry><link linkend="KeyboardHIDType">KeyboardHIDType</link></entry>
5819 </row>
5820 <row>
5821 <entry>IPciAddress</entry>
5822 <entry><link linkend="IPCIAddress">IPCIAddress</link></entry>
5823 </row>
5824 <row>
5825 <entry>IPciDeviceAttachment</entry>
5826 <entry><link linkend="IPCIDeviceAttachment">IPCIDeviceAttachment</link></entry>
5827 </row>
5828 <row>
5829 <entry>IMachine::pointingHidType</entry>
5830 <entry><link linkend="IMachine__pointingHIDType">IMachine::pointingHIDType</link></entry>
5831 </row>
5832 <row>
5833 <entry>IMachine::keyboardHidType</entry>
5834 <entry><link linkend="IMachine__keyboardHIDType">IMachine::keyboardHIDType</link></entry>
5835 </row>
5836 <row>
5837 <entry>IMachine::hpetEnabled</entry>
5838 <entry>IMachine::HPETEnabled</entry>
5839 </row>
5840 <row>
5841 <entry>IMachine::sessionPid</entry>
5842 <entry><link linkend="IMachine__sessionPID">IMachine::sessionPID</link></entry>
5843 </row>
5844 <row>
5845 <entry>IMachine::ioCacheEnabled</entry>
5846 <entry><link linkend="IMachine__IOCacheEnabled">IMachine::IOCacheEnabled</link></entry>
5847 </row>
5848 <row>
5849 <entry>IMachine::ioCacheSize</entry>
5850 <entry><link linkend="IMachine__IOCacheSize">IMachine::IOCacheSize</link></entry>
5851 </row>
5852 <row>
5853 <entry>IMachine::pciDeviceAssignments</entry>
5854 <entry><link linkend="IMachine__PCIDeviceAssignments">IMachine::PCIDeviceAssignments</link></entry>
5855 </row>
5856 <row>
5857 <entry>IMachine::attachHostPciDevice()</entry>
5858 <entry><link linkend="IMachine__attachHostPCIDevice">IMachine::attachHostPCIDevice</link></entry>
5859 </row>
5860 <row>
5861 <entry>IMachine::detachHostPciDevice()</entry>
5862 <entry><link linkend="IMachine__detachHostPCIDevice">IMachine::detachHostPCIDevice()</link></entry>
5863 </row>
5864 <row>
5865 <entry>IConsole::attachedPciDevices</entry>
5866 <entry><link linkend="IConsole__attachedPCIDevices">IConsole::attachedPCIDevices</link></entry>
5867 </row>
5868 <row>
5869 <entry>IHostNetworkInterface::dhcpEnabled</entry>
5870 <entry><link linkend="IHostNetworkInterface__DHCPEnabled">IHostNetworkInterface::DHCPEnabled</link></entry>
5871 </row>
5872 <row>
5873 <entry>IHostNetworkInterface::enableStaticIpConfig()</entry>
5874 <entry><link linkend="IHostNetworkInterface__enableStaticIPConfig">IHostNetworkInterface::enableStaticIPConfig()</link></entry>
5875 </row>
5876 <row>
5877 <entry>IHostNetworkInterface::enableStaticIpConfigV6()</entry>
5878 <entry><link linkend="IHostNetworkInterface__enableStaticIPConfigV6">IHostNetworkInterface::enableStaticIPConfigV6()</link></entry>
5879 </row>
5880 <row>
5881 <entry>IHostNetworkInterface::enableDynamicIpConfig()</entry>
5882 <entry><link linkend="IHostNetworkInterface__enableDynamicIPConfig">IHostNetworkInterface::enableDynamicIPConfig()</link></entry>
5883 </row>
5884 <row>
5885 <entry>IHostNetworkInterface::dhcpRediscover()</entry>
5886 <entry><link linkend="IHostNetworkInterface__DHCPRediscover">IHostNetworkInterface::DHCPRediscover()</link></entry>
5887 </row>
5888 <row>
5889 <entry>IHost::Acceleration3DAvailable</entry>
5890 <entry><link linkend="IHost__acceleration3DAvailable">IHost::acceleration3DAvailable</link></entry>
5891 </row>
5892 <row>
5893 <entry>IGuestOSType::recommendedPae</entry>
5894 <entry><link linkend="IGuestOSType__recommendedPAE">IGuestOSType::recommendedPAE</link></entry>
5895 </row>
5896 <row>
5897 <entry>IGuestOSType::recommendedDvdStorageController</entry>
5898 <entry><link linkend="IGuestOSType__recommendedDVDStorageController">IGuestOSType::recommendedDVDStorageController</link></entry>
5899 </row>
5900 <row>
5901 <entry>IGuestOSType::recommendedDvdStorageBus</entry>
5902 <entry><link linkend="IGuestOSType__recommendedDVDStorageBus">IGuestOSType::recommendedDVDStorageBus</link></entry>
5903 </row>
5904 <row>
5905 <entry>IGuestOSType::recommendedHdStorageController</entry>
5906 <entry><link linkend="IGuestOSType__recommendedHDStorageController">IGuestOSType::recommendedHDStorageController</link></entry>
5907 </row>
5908 <row>
5909 <entry>IGuestOSType::recommendedHdStorageBus</entry>
5910 <entry><link linkend="IGuestOSType__recommendedHDStorageBus">IGuestOSType::recommendedHDStorageBus</link></entry>
5911 </row>
5912 <row>
5913 <entry>IGuestOSType::recommendedUsbHid</entry>
5914 <entry><link linkend="IGuestOSType__recommendedUSBHID">IGuestOSType::recommendedUSBHID</link></entry>
5915 </row>
5916 <row>
5917 <entry>IGuestOSType::recommendedHpet</entry>
5918 <entry><link linkend="IGuestOSType__recommendedHPET">IGuestOSType::recommendedHPET</link></entry>
5919 </row>
5920 <row>
5921 <entry>IGuestOSType::recommendedUsbTablet</entry>
5922 <entry><link linkend="IGuestOSType__recommendedUSBTablet">IGuestOSType::recommendedUSBTablet</link></entry>
5923 </row>
5924 <row>
5925 <entry>IGuestOSType::recommendedRtcUseUtc</entry>
5926 <entry><link linkend="IGuestOSType__recommendedRTCUseUTC">IGuestOSType::recommendedRTCUseUTC</link></entry>
5927 </row>
5928 <row>
5929 <entry>IGuestOSType::recommendedUsb</entry>
5930 <entry><link linkend="IGuestOSType__recommendedUSB">IGuestOSType::recommendedUSB</link></entry>
5931 </row>
5932 <row>
5933 <entry>INetworkAdapter::natDriver</entry>
5934 <entry><link linkend="INetworkAdapter__NATEngine">INetworkAdapter::NATEngine</link></entry>
5935 </row>
5936 <row>
5937 <entry>IUSBController::enabledEhci</entry>
5938 <entry>IUSBController::enabledEHCI"</entry>
5939 </row>
5940 <row>
5941 <entry>INATEngine::tftpPrefix</entry>
5942 <entry><link linkend="INATEngine__TFTPPrefix">INATEngine::TFTPPrefix</link></entry>
5943 </row>
5944 <row>
5945 <entry>INATEngine::tftpBootFile</entry>
5946 <entry><link linkend="INATEngine__TFTPBootFile">INATEngine::TFTPBootFile</link></entry>
5947 </row>
5948 <row>
5949 <entry>INATEngine::tftpNextServer</entry>
5950 <entry><link linkend="INATEngine__TFTPNextServer">INATEngine::TFTPNextServer</link></entry>
5951 </row>
5952 <row>
5953 <entry>INATEngine::dnsPassDomain</entry>
5954 <entry><link linkend="INATEngine__DNSPassDomain">INATEngine::DNSPassDomain</link></entry>
5955 </row>
5956 <row>
5957 <entry>INATEngine::dnsProxy</entry>
5958 <entry><link linkend="INATEngine__DNSProxy">INATEngine::DNSProxy</link></entry>
5959 </row>
5960 <row>
5961 <entry>INATEngine::dnsUseHostResolver</entry>
5962 <entry><link linkend="INATEngine__DNSUseHostResolver">INATEngine::DNSUseHostResolver</link></entry>
5963 </row>
5964 <row>
5965 <entry>VBoxEventType::OnHostPciDevicePlug</entry>
5966 <entry><link linkend="VBoxEventType__OnHostPCIDevicePlug">VBoxEventType::OnHostPCIDevicePlug</link></entry>
5967 </row>
5968 <row>
5969 <entry>ICPUChangedEvent::cpu</entry>
5970 <entry><link linkend="ICPUChangedEvent__CPU">ICPUChangedEvent::CPU</link></entry>
5971 </row>
5972 <row>
5973 <entry>INATRedirectEvent::hostIp</entry>
5974 <entry><link linkend="INATRedirectEvent__hostIP">INATRedirectEvent::hostIP</link></entry>
5975 </row>
5976 <row>
5977 <entry>INATRedirectEvent::guestIp</entry>
5978 <entry><link linkend="INATRedirectEvent__guestIP">INATRedirectEvent::guestIP</link></entry>
5979 </row>
5980 <row>
5981 <entry>IHostPciDevicePlugEvent</entry>
5982 <entry><link linkend="IHostPCIDevicePlugEvent">IHostPCIDevicePlugEvent</link></entry>
5983 </row>
5984 </tbody>
5985 </tgroup></table></para>
5986 </listitem>
5987 </itemizedlist>
5988 </sect1>
5989
5990 <sect1>
5991 <title>Incompatible API changes with version 4.1</title>
5992
5993 <itemizedlist>
5994 <listitem>
5995 <para>The method
5996 <link linkend="IAppliance__importMachines">IAppliance::importMachines()</link>
5997 has one more parameter now, which allows to configure the import
5998 process in more detail.
5999 </para>
6000 </listitem>
6001
6002 <listitem>
6003 <para>The method
6004 <link linkend="IVirtualBox__openMedium">IVirtualBox::openMedium()</link>
6005 has one more parameter now, which allows resolving duplicate medium
6006 UUIDs without the need for external tools.</para>
6007 </listitem>
6008
6009 <listitem>
6010 <para>The <link linkend="INetworkAdapter">INetworkAdapter</link>
6011 interface has been cleaned up. The various methods to activate an
6012 attachment type have been replaced by the
6013 <link linkend="INetworkAdapter__attachmentType">INetworkAdapter::attachmentType</link>
6014 setter.</para>
6015 <para>Additionally each attachment mode now has its own attribute,
6016 which means that host only networks no longer share the settings with
6017 bridged interfaces.</para>
6018 <para>To allow introducing new network attachment implementations
6019 without making API changes, the concept of a generic network
6020 attachment driver has been introduced, which is configurable through
6021 key/value properties.</para>
6022 </listitem>
6023
6024 <listitem>
6025 <para>This version introduces the guest facilities concept. A guest
6026 facility either represents a module or feature the guest is running
6027 or offering, which is defined by
6028 <link linkend="AdditionsFacilityType">AdditionsFacilityType</link>.
6029 Each facility is member of a
6030 <link linkend="AdditionsFacilityClass">AdditionsFacilityClass</link>
6031 and has a current status indicated by
6032 <link linkend="AdditionsFacilityStatus">AdditionsFacilityStatus</link>,
6033 together with a timestamp (in ms) of the last status update.</para>
6034 <para>To address the above concept, the following changes were made:
6035 <itemizedlist>
6036 <listitem>
6037 <para>
6038 In the <link linkend="IGuest">IGuest</link> interface, the
6039 following were removed:
6040 <itemizedlist>
6041 <listitem>
6042 <para>the
6043 <computeroutput>supportsSeamless</computeroutput>
6044 attribute;</para>
6045 </listitem>
6046 <listitem>
6047 <para>the
6048 <computeroutput>supportsGraphics</computeroutput>
6049 attribute;</para>
6050 </listitem>
6051 </itemizedlist>
6052 </para>
6053 </listitem>
6054 <listitem>
6055 <para>
6056 The function
6057 <link linkend="IGuest__getFacilityStatus">IGuest::getFacilityStatus()</link>
6058 was added. It quickly provides a facility's status without
6059 the need to get the facility collection with
6060 <link linkend="IGuest__facilities">IGuest::facilities</link>.
6061 </para>
6062 </listitem>
6063 <listitem>
6064 <para>
6065 The attribute
6066 <link linkend="IGuest__facilities">IGuest::facilities</link>
6067 was added to provide an easy to access collection of all
6068 currently known guest facilities, that is, it contains all
6069 facilies where at least one status update was made since the
6070 guest was started.
6071 </para>
6072 </listitem>
6073 <listitem>
6074 <para>
6075 The interface
6076 <link linkend="IAdditionsFacility">IAdditionsFacility</link>
6077 was added to represent a single facility returned by
6078 <link linkend="IGuest__facilities">IGuest::facilities</link>.
6079 </para>
6080 </listitem>
6081 <listitem>
6082 <para>
6083 <link linkend="AdditionsFacilityStatus">AdditionsFacilityStatus</link>
6084 was added to represent a facility's overall status.
6085 </para>
6086 </listitem>
6087 <listitem>
6088 <para>
6089 <link linkend="AdditionsFacilityType">AdditionsFacilityType</link> and
6090 <link linkend="AdditionsFacilityClass">AdditionsFacilityClass</link> were
6091 added to represent the facility's type and class.
6092 </para>
6093 </listitem>
6094 </itemizedlist>
6095 </para>
6096 </listitem>
6097 </itemizedlist>
6098 </sect1>
6099
6100 <sect1>
6101 <title>Incompatible API changes with version 4.0</title>
6102
6103 <itemizedlist>
6104 <listitem>
6105 <para>A new Java glue layer replacing the previous OOWS JAX-WS
6106 bindings was introduced. The new library allows for uniform code
6107 targeting both local (COM/XPCOM) and remote (SOAP) transports. Now,
6108 instead of <computeroutput>IWebsessionManager</computeroutput>, the
6109 new class <computeroutput>VirtualBoxManager</computeroutput> must be
6110 used. See <xref linkend="javaapi"/> for details.</para>
6111 </listitem>
6112
6113 <listitem>
6114 <para>The confusingly named and impractical session APIs were
6115 changed. In existing client code, the following changes need to be
6116 made:<itemizedlist>
6117 <listitem>
6118 <para>Replace any
6119 <computeroutput>IVirtualBox::openSession(uuidMachine,
6120 ...)</computeroutput> API call with the machine's
6121 <link linkend="IMachine__lockMachine">IMachine::lockMachine()</link>
6122 call and a
6123 <computeroutput>LockType.Write</computeroutput> argument. The
6124 functionality is unchanged, but instead of "opening a direct
6125 session on a machine" all documentation now refers to
6126 "obtaining a write lock on a machine for the client
6127 session".</para>
6128 </listitem>
6129
6130 <listitem>
6131 <para>Similarly, replace any
6132 <computeroutput>IVirtualBox::openExistingSession(uuidMachine,
6133 ...)</computeroutput> call with the machine's
6134 <link linkend="IMachine__lockMachine">IMachine::lockMachine()</link>
6135 call and a <computeroutput>LockType.Shared</computeroutput>
6136 argument. Whereas it was previously impossible to connect a
6137 client session to a running VM process in a race-free manner,
6138 the new API will atomically either write-lock the machine for
6139 the current session or establish a remote link to an existing
6140 session. Existing client code which tried calling both
6141 <computeroutput>openSession()</computeroutput> and
6142 <computeroutput>openExistingSession()</computeroutput> can now
6143 use this one call instead.</para>
6144 </listitem>
6145
6146 <listitem>
6147 <para>Third, replace any
6148 <computeroutput>IVirtualBox::openRemoteSession(uuidMachine,
6149 ...)</computeroutput> call with the machine's
6150 <link linkend="IMachine__launchVMProcess">IMachine::launchVMProcess()</link>
6151 call. The functionality is unchanged.</para>
6152 </listitem>
6153
6154 <listitem>
6155 <para>The <link linkend="SessionState">SessionState</link> enum
6156 was adjusted accordingly: "Open" is now "Locked", "Closed" is
6157 now "Unlocked", "Closing" is now "Unlocking".</para>
6158 </listitem>
6159 </itemizedlist></para>
6160 </listitem>
6161
6162 <listitem>
6163 <para>Virtual machines created with VirtualBox 4.0 or later no
6164 longer register their media in the global media registry in the
6165 <computeroutput>VirtualBox.xml</computeroutput> file. Instead, such
6166 machines list all their media in their own machine XML files. As a
6167 result, a number of media-related APIs had to be modified again.
6168 <itemizedlist>
6169 <listitem>
6170 <para>Neither
6171 <computeroutput>IVirtualBox::createHardDisk()</computeroutput>
6172 nor
6173 <link linkend="IVirtualBox__openMedium">IVirtualBox::openMedium()</link>
6174 register media automatically any more.</para>
6175 </listitem>
6176
6177 <listitem>
6178 <para><link linkend="IMachine__attachDevice">IMachine::attachDevice()</link>
6179 and
6180 <link linkend="IMachine__mountMedium">IMachine::mountMedium()</link>
6181 now take an IMedium object instead of a UUID as an argument. It
6182 is these two calls which add media to a registry now (either a
6183 machine registry for machines created with VirtualBox 4.0 or
6184 later or the global registry otherwise). As a consequence, if a
6185 medium is opened but never attached to a machine, it is no
6186 longer added to any registry any more.</para>
6187 </listitem>
6188
6189 <listitem>
6190 <para>To reduce code duplication, the APIs
6191 IVirtualBox::findHardDisk(), getHardDisk(), findDVDImage(),
6192 getDVDImage(), findFloppyImage() and getFloppyImage() have all
6193 been merged into IVirtualBox::findMedium(), and
6194 IVirtualBox::openHardDisk(), openDVDImage() and
6195 openFloppyImage() have all been merged into
6196 <link linkend="IVirtualBox__openMedium">IVirtualBox::openMedium()</link>.</para>
6197 </listitem>
6198
6199 <listitem>
6200 <para>The rare use case of changing the UUID and parent UUID
6201 of a medium previously handled by
6202 <computeroutput>openHardDisk()</computeroutput> is now in a
6203 separate IMedium::setIDs method.</para>
6204 </listitem>
6205
6206 <listitem>
6207 <para><computeroutput>ISystemProperties::get/setDefaultHardDiskFolder()</computeroutput>
6208 have been removed since disk images are now by default placed
6209 in each machine's folder.</para>
6210 </listitem>
6211
6212 <listitem>
6213 <para>The
6214 <link linkend="ISystemProperties__infoVDSize">ISystemProperties::infoVDSize</link>
6215 attribute replaces the
6216 <computeroutput>getMaxVDISize()</computeroutput>
6217 API call; this now uses bytes instead of megabytes.</para>
6218 </listitem>
6219 </itemizedlist></para>
6220 </listitem>
6221
6222 <listitem>
6223 <para>Machine management APIs were enhanced as follows:<itemizedlist>
6224 <listitem>
6225 <para><link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
6226 is no longer restricted to creating machines in the default
6227 "Machines" folder, but can now create machines at arbitrary
6228 locations. For this to work, the parameter list had to be
6229 changed.</para>
6230 </listitem>
6231
6232 <listitem>
6233 <para>The long-deprecated
6234 <computeroutput>IVirtualBox::createLegacyMachine()</computeroutput>
6235 API has been removed.</para>
6236 </listitem>
6237
6238 <listitem>
6239 <para>To reduce code duplication and for consistency with the
6240 aforementioned media APIs,
6241 <computeroutput>IVirtualBox::getMachine()</computeroutput> has
6242 been merged with
6243 <link linkend="IVirtualBox__findMachine">IVirtualBox::findMachine()</link>,
6244 and
6245 <computeroutput>IMachine::getSnapshot()</computeroutput> has
6246 been merged with
6247 <link linkend="IMachine__findSnapshot">IMachine::findSnapshot()</link>.</para>
6248 </listitem>
6249
6250 <listitem>
6251 <para><computeroutput>IVirtualBox::unregisterMachine()</computeroutput>
6252 was replaced with
6253 <link linkend="IMachine__unregister">IMachine::unregister()</link>
6254 with additional functionality for cleaning up machine
6255 files.</para>
6256 </listitem>
6257
6258 <listitem>
6259 <para><computeroutput>IMachine::deleteSettings</computeroutput>
6260 has been replaced by IMachine::delete, which allows specifying
6261 which disk images are to be deleted as part of the deletion,
6262 and because it can take a while it also returns a
6263 <computeroutput>IProgress</computeroutput> object reference,
6264 so that the completion of the asynchronous activities can be
6265 monitored.</para>
6266 </listitem>
6267
6268 <listitem>
6269 <para><computeroutput>IConsole::forgetSavedState</computeroutput>
6270 has been renamed to
6271 <computeroutput>IConsole::discardSavedState()</computeroutput>.</para>
6272 </listitem>
6273 </itemizedlist></para>
6274 </listitem>
6275
6276 <listitem>
6277 <para>All event callbacks APIs were replaced with a new, generic
6278 event mechanism that can be used both locally (COM, XPCOM) and
6279 remotely (web services). Also, the new mechanism is usable from
6280 scripting languages and a local Java. See
6281 <link linkend="IEvent">events</link> for details. The new concept
6282 will require changes to all clients that used event callbacks.</para>
6283 </listitem>
6284
6285 <listitem>
6286 <para><computeroutput>additionsActive()</computeroutput> was replaced
6287 with
6288 <link linkend="IGuest__additionsRunLevel">additionsRunLevel()</link>
6289 and
6290 <link linkend="IGuest__getAdditionsStatus">getAdditionsStatus()</link>
6291 in order to support a more detailed status of the current Guest
6292 Additions loading/readiness state.
6293 <link linkend="IGuest__additionsVersion">IGuest::additionsVersion()</link>
6294 no longer returns the Guest Additions interface version but the
6295 installed Guest Additions version and revision in form of
6296 <computeroutput>3.3.0r12345</computeroutput>.</para>
6297 </listitem>
6298
6299 <listitem>
6300 <para>To address shared folders auto-mounting support, the following
6301 APIs were extended to require an additional
6302 <computeroutput>automount</computeroutput> parameter: <itemizedlist>
6303 <listitem>
6304 <para><link linkend="IVirtualBox__createSharedFolder">IVirtualBox::createSharedFolder()</link></para>
6305 </listitem>
6306
6307 <listitem>
6308 <para><link linkend="IMachine__createSharedFolder">IMachine::createSharedFolder()</link></para>
6309 </listitem>
6310
6311 <listitem>
6312 <para><link linkend="IConsole__createSharedFolder">IConsole::createSharedFolder()</link></para>
6313 </listitem>
6314 </itemizedlist> Also, a new property named
6315 <computeroutput>autoMount</computeroutput> was added to the
6316 <link linkend="ISharedFolder">ISharedFolder</link>
6317 interface.</para>
6318 </listitem>
6319
6320 <listitem>
6321 <para>The appliance (OVF) APIs were enhanced as
6322 follows:<itemizedlist>
6323 <listitem>
6324 <para><computeroutput>IMachine::export</computeroutput>
6325 received an extra parameter
6326 <computeroutput>location</computeroutput>, which is used to
6327 decide for the disk naming.</para>
6328 </listitem>
6329
6330 <listitem>
6331 <para><link linkend="IAppliance__write">IAppliance::write()</link>
6332 received an extra parameter
6333 <computeroutput>manifest</computeroutput>, which can suppress
6334 creating the manifest file on export.</para>
6335 </listitem>
6336
6337 <listitem>
6338 <para><link linkend="IVFSExplorer__entryList">IVFSExplorer::entryList()</link>
6339 received two extra parameters
6340 <computeroutput>sizes</computeroutput> and
6341 <computeroutput>modes</computeroutput>, which contains the
6342 sizes (in bytes) and the file access modes (in octal form) of
6343 the returned files.</para>
6344 </listitem>
6345 </itemizedlist></para>
6346 </listitem>
6347
6348 <listitem>
6349 <para>Support for remote desktop access to virtual machines has been
6350 cleaned up to allow third party implementations of the remote
6351 desktop server. This is called the VirtualBox Remote Desktop
6352 Extension (VRDE) and can be added to VirtualBox by installing the
6353 corresponding extension package; see the VirtualBox User Manual for
6354 details.</para>
6355
6356 <para>The following API changes were made to support the VRDE
6357 interface: <itemizedlist>
6358 <listitem>
6359 <para><computeroutput>IVRDPServer</computeroutput> has been
6360 renamed to
6361 <link linkend="IVRDEServer">IVRDEServer</link>.</para>
6362 </listitem>
6363
6364 <listitem>
6365 <para><computeroutput>IRemoteDisplayInfo</computeroutput> has
6366 been renamed to
6367 <link linkend="IVRDEServerInfo">IVRDEServerInfo</link>.</para>
6368 </listitem>
6369
6370 <listitem>
6371 <para><link linkend="IMachine__VRDEServer">IMachine::VRDEServer</link>
6372 replaces
6373 <computeroutput>VRDPServer.</computeroutput></para>
6374 </listitem>
6375
6376 <listitem>
6377 <para><link linkend="IConsole__VRDEServerInfo">IConsole::VRDEServerInfo</link>
6378 replaces
6379 <computeroutput>RemoteDisplayInfo</computeroutput>.</para>
6380 </listitem>
6381
6382 <listitem>
6383 <para><link linkend="ISystemProperties__VRDEAuthLibrary">ISystemProperties::VRDEAuthLibrary</link>
6384 replaces
6385 <computeroutput>RemoteDisplayAuthLibrary</computeroutput>.</para>
6386 </listitem>
6387
6388 <listitem>
6389 <para>The following methods have been implemented in
6390 <computeroutput>IVRDEServer</computeroutput> to support
6391 generic VRDE properties: <itemizedlist>
6392 <listitem>
6393 <para><link linkend="IVRDEServer__setVRDEProperty">IVRDEServer::setVRDEProperty</link></para>
6394 </listitem>
6395
6396 <listitem>
6397 <para><link linkend="IVRDEServer__getVRDEProperty">IVRDEServer::getVRDEProperty</link></para>
6398 </listitem>
6399
6400 <listitem>
6401 <para><link linkend="IVRDEServer__VRDEProperties">IVRDEServer::VRDEProperties</link></para>
6402 </listitem>
6403 </itemizedlist></para>
6404
6405 <para>A few implementation-specific attributes of the old
6406 <computeroutput>IVRDPServer</computeroutput> interface have
6407 been removed and replaced with properties: <itemizedlist>
6408 <listitem>
6409 <para><computeroutput>IVRDPServer::Ports</computeroutput>
6410 has been replaced with the
6411 <computeroutput>"TCP/Ports"</computeroutput> property.
6412 The property value is a string, which contains a
6413 comma-separated list of ports or ranges of ports. Use a
6414 dash between two port numbers to specify a range.
6415 Example:
6416 <computeroutput>"5000,5010-5012"</computeroutput></para>
6417 </listitem>
6418
6419 <listitem>
6420 <para><computeroutput>IVRDPServer::NetAddress</computeroutput>
6421 has been replaced with the
6422 <computeroutput>"TCP/Address"</computeroutput> property.
6423 The property value is an IP address string. Example:
6424 <computeroutput>"127.0.0.1"</computeroutput></para>
6425 </listitem>
6426
6427 <listitem>
6428 <para><computeroutput>IVRDPServer::VideoChannel</computeroutput>
6429 has been replaced with the
6430 <computeroutput>"VideoChannel/Enabled"</computeroutput>
6431 property. The property value is either
6432 <computeroutput>"true"</computeroutput> or
6433 <computeroutput>"false"</computeroutput></para>
6434 </listitem>
6435
6436 <listitem>
6437 <para><computeroutput>IVRDPServer::VideoChannelQuality</computeroutput>
6438 has been replaced with the
6439 <computeroutput>"VideoChannel/Quality"</computeroutput>
6440 property. The property value is a string which contain a
6441 decimal number in range 10..100. Invalid values are
6442 ignored and the quality is set to the default value 75.
6443 Example: <computeroutput>"50"</computeroutput></para>
6444 </listitem>
6445 </itemizedlist></para>
6446 </listitem>
6447 </itemizedlist></para>
6448 </listitem>
6449
6450 <listitem>
6451 <para>The VirtualBox external authentication module interface has
6452 been updated and made more generic. Because of that,
6453 <computeroutput>VRDPAuthType</computeroutput> enumeration has been
6454 renamed to <link linkend="AuthType">AuthType</link>.</para>
6455 </listitem>
6456 </itemizedlist>
6457 </sect1>
6458
6459 <sect1>
6460 <title>Incompatible API changes with version 3.2</title>
6461
6462 <itemizedlist>
6463 <listitem>
6464 <para>The following interfaces were renamed for consistency:
6465 <itemizedlist>
6466 <listitem>
6467 <para>IMachine::getCpuProperty() is now IMachine::getCPUProperty();</para>
6468 </listitem>
6469
6470 <listitem>
6471 <para>IMachine::setCpuProperty() is now IMachine::setCPUProperty();</para>
6472 </listitem>
6473
6474 <listitem>
6475 <para>IMachine::getCpuIdLeaf() is now IMachine::getCPUIDLeaf();</para>
6476 </listitem>
6477
6478 <listitem>
6479 <para>IMachine::setCpuIdLeaf() is now IMachine::setCPUIDLeaf();</para>
6480 </listitem>
6481
6482 <listitem>
6483 <para>IMachine::removeCpuIdLeaf() is now IMachine::removeCPUIDLeaf();</para>
6484 </listitem>
6485
6486 <listitem>
6487 <para>IMachine::removeAllCpuIdLeafs() is now IMachine::removeAllCPUIDLeaves();</para>
6488 </listitem>
6489
6490 <listitem>
6491 <para>the CpuPropertyType enum is now CPUPropertyType.</para>
6492 </listitem>
6493
6494 <listitem>
6495 <para>IVirtualBoxCallback::onSnapshotDiscarded() is now
6496 IVirtualBoxCallback::onSnapshotDeleted.</para>
6497 </listitem>
6498 </itemizedlist></para>
6499 </listitem>
6500
6501 <listitem>
6502 <para>When creating a VM configuration with
6503 <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
6504 it is now possible to ignore existing configuration files which would
6505 previously have caused a failure. For this the
6506 <computeroutput>override</computeroutput> parameter was added.</para>
6507 </listitem>
6508
6509 <listitem>
6510 <para>Deleting snapshots via
6511 <computeroutput>IConsole::deleteSnapshot()</computeroutput> is now
6512 possible while the associated VM is running in almost all cases.
6513 The API is unchanged, but client code that verifies machine states
6514 to determine whether snapshots can be deleted may need to be
6515 adjusted.</para>
6516 </listitem>
6517
6518 <listitem>
6519 <para>The IoBackendType enumeration was replaced with a boolean flag
6520 (see
6521 <link linkend="IStorageController__useHostIOCache">IStorageController::useHostIOCache</link>).</para>
6522 </listitem>
6523
6524 <listitem>
6525 <para>To address multi-monitor support, the following APIs were
6526 extended to require an additional
6527 <computeroutput>screenId</computeroutput> parameter: <itemizedlist>
6528 <listitem>
6529 <para>IMachine::querySavedThumbnailSize()</para>
6530 </listitem>
6531
6532 <listitem>
6533 <para><link linkend="IMachine__readSavedThumbnailToArray">IMachine::readSavedThumbnailToArray()</link></para>
6534 </listitem>
6535
6536 <listitem>
6537 <para><link linkend="IMachine__querySavedScreenshotInfo">IMachine::querySavedScreenshotPNGSize()</link></para>
6538 </listitem>
6539
6540 <listitem>
6541 <para><link linkend="IMachine__readSavedScreenshotToArray">IMachine::readSavedScreenshotPNGToArray()</link></para>
6542 </listitem>
6543 </itemizedlist></para>
6544 </listitem>
6545
6546 <listitem>
6547 <para>The <computeroutput>shape</computeroutput> parameter of
6548 IConsoleCallback::onMousePointerShapeChange was changed from a
6549 implementation-specific pointer to a safearray, enabling scripting
6550 languages to process pointer shapes.</para>
6551 </listitem>
6552 </itemizedlist>
6553 </sect1>
6554
6555 <sect1>
6556 <title>Incompatible API changes with version 3.1</title>
6557
6558 <itemizedlist>
6559 <listitem>
6560 <para>Due to the new flexibility in medium attachments that was
6561 introduced with version 3.1 (in particular, full flexibility with
6562 attaching CD/DVD drives to arbitrary controllers), we seized the
6563 opportunity to rework all interfaces dealing with storage media to
6564 make the API more flexible as well as logical. The
6565 <link linkend="IStorageController">IStorageController</link>,
6566 <link linkend="IMedium">IMedium</link>,
6567 <link linkend="IMediumAttachment">IMediumAttachment</link> and
6568 <link linkend="IMachine">IMachine</link> interfaces were
6569 affected the most. Existing code using them to configure storage and
6570 media needs to be carefully checked.</para>
6571
6572 <para>All media (hard disks, floppies and CDs/DVDs) are now
6573 uniformly handled through the <link linkend="IMedium">IMedium</link>
6574 interface. The device-specific interfaces
6575 (<code>IHardDisk</code>, <code>IDVDImage</code>,
6576 <code>IHostDVDDrive</code>, <code>IFloppyImage</code> and
6577 <code>IHostFloppyDrive</code>) have been merged into IMedium; CD/DVD
6578 and floppy media no longer need special treatment. The device type
6579 of a medium determines in which context it can be used. Some
6580 functionality was moved to the other storage-related
6581 interfaces.</para>
6582
6583 <para><code>IMachine::attachHardDisk</code> and similar methods have
6584 been renamed and generalized to deal with any type of drive and
6585 medium.
6586 <link linkend="IMachine__attachDevice">IMachine::attachDevice()</link>
6587 is the API method for adding any drive to a storage controller. The
6588 floppy and DVD/CD drives are no longer handled specially, and that
6589 means you can have more than one of them. As before, drives can only
6590 be changed while the VM is powered off. Mounting (or unmounting)
6591 removable media at runtime is possible with
6592 <link linkend="IMachine__mountMedium">IMachine::mountMedium()</link>.</para>
6593
6594 <para>Newly created virtual machines have no storage controllers
6595 associated with them. Even the IDE Controller needs to be created
6596 explicitly. The floppy controller is now visible as a separate
6597 controller, with a new storage bus type. For each storage bus type
6598 you can query the device types which can be attached, so that it is
6599 not necessary to hardcode any attachment rules.</para>
6600
6601 <para>This required matching changes e.g. in the callback interfaces
6602 (the medium specific change notification was replaced by a generic
6603 medium change notification) and removing associated enums (e.g.
6604 <code>DriveState</code>). In many places the incorrect use of the
6605 plural form "media" was replaced by "medium", to improve
6606 consistency.</para>
6607 </listitem>
6608
6609 <listitem>
6610 <para>Reading the
6611 <link linkend="IMedium__state">IMedium::state</link> attribute no
6612 longer automatically performs an accessibility check; a new method
6613 <link linkend="IMedium__refreshState">IMedium::refreshState()</link>
6614 does this. The attribute only returns the state now.</para>
6615 </listitem>
6616
6617 <listitem>
6618 <para>There were substantial changes related to snapshots, triggered
6619 by the "branched snapshots" functionality introduced with version
6620 3.1. IConsole::discardSnapshot was renamed to
6621 <computeroutput>IConsole::deleteSnapshot()</computeroutput>.
6622 IConsole::discardCurrentState and
6623 IConsole::discardCurrentSnapshotAndState were removed; corresponding
6624 new functionality is in
6625 <computeroutput>IConsole::restoreSnapshot()</computeroutput>.
6626 Also, when <computeroutput>IConsole::takeSnapshot()</computeroutput>
6627 is called on a running virtual machine, a live snapshot will be
6628 created. The old behavior was to temporarily pause the virtual
6629 machine while creating an online snapshot.</para>
6630 </listitem>
6631
6632 <listitem>
6633 <para>The <computeroutput>IVRDPServer</computeroutput>,
6634 <computeroutput>IRemoteDisplayInfo"</computeroutput> and
6635 <computeroutput>IConsoleCallback</computeroutput> interfaces were
6636 changed to reflect VRDP server ability to bind to one of available
6637 ports from a list of ports.</para>
6638
6639 <para>The <computeroutput>IVRDPServer::port</computeroutput>
6640 attribute has been replaced with
6641 <computeroutput>IVRDPServer::ports</computeroutput>, which is a
6642 comma-separated list of ports or ranges of ports.</para>
6643
6644 <para>An <computeroutput>IRemoteDisplayInfo::port"</computeroutput>
6645 attribute has been added for querying the actual port VRDP server
6646 listens on.</para>
6647
6648 <para>An IConsoleCallback::onRemoteDisplayInfoChange() notification
6649 callback has been added.</para>
6650 </listitem>
6651
6652 <listitem>
6653 <para>The parameter lists for the following functions were
6654 modified:<itemizedlist>
6655 <listitem>
6656 <para><link linkend="IHost__removeHostOnlyNetworkInterface">IHost::removeHostOnlyNetworkInterface()</link></para>
6657 </listitem>
6658
6659 <listitem>
6660 <para><link linkend="IHost__removeUSBDeviceFilter">IHost::removeUSBDeviceFilter()</link></para>
6661 </listitem>
6662 </itemizedlist></para>
6663 </listitem>
6664
6665 <listitem>
6666 <para>In the OOWS bindings for JAX-WS, the behavior of structures
6667 changed: for one, we implemented natural structures field access so
6668 you can just call a "get" method to obtain a field. Secondly,
6669 setters in structures were disabled as they have no expected effect
6670 and were at best misleading.</para>
6671 </listitem>
6672 </itemizedlist>
6673 </sect1>
6674
6675 <sect1>
6676 <title>Incompatible API changes with version 3.0</title>
6677
6678 <itemizedlist>
6679 <listitem>
6680 <para>In the object-oriented web service bindings for JAX-WS, proper
6681 inheritance has been introduced for some classes, so explicit
6682 casting is no longer needed to call methods from a parent class. In
6683 particular, IHardDisk and other classes now properly derive from
6684 <link linkend="IMedium">IMedium</link>.</para>
6685 </listitem>
6686
6687 <listitem>
6688 <para>All object identifiers (machines, snapshots, disks, etc)
6689 switched from GUIDs to strings (now still having string
6690 representation of GUIDs inside). As a result, no particular internal
6691 structure can be assumed for object identifiers; instead, they
6692 should be treated as opaque unique handles. This change mostly
6693 affects Java and C++ programs; for other languages, GUIDs are
6694 transparently converted to strings.</para>
6695 </listitem>
6696
6697 <listitem>
6698 <para>The uses of NULL strings have been changed greatly. All out
6699 parameters now use empty strings to signal a null value. For in
6700 parameters both the old NULL and empty string is allowed. This
6701 change was necessary to support more client bindings, especially
6702 using the web service API. Many of them either have no special NULL
6703 value or have trouble dealing with it correctly in the respective
6704 library code.</para>
6705 </listitem>
6706
6707 <listitem>
6708 <para>Accidentally, the <code>TSBool</code> interface still appeared
6709 in 3.0.0, and was removed in 3.0.2. This is an SDK bug, do not use
6710 the SDK for VirtualBox 3.0.0 for developing clients.</para>
6711 </listitem>
6712
6713 <listitem>
6714 <para>The type of
6715 <link linkend="IVirtualBoxErrorInfo__resultCode">IVirtualBoxErrorInfo::resultCode</link>
6716 changed from
6717 <computeroutput>result</computeroutput> to
6718 <computeroutput>long</computeroutput>.</para>
6719 </listitem>
6720
6721 <listitem>
6722 <para>The parameter list of IVirtualBox::openHardDisk was
6723 changed.</para>
6724 </listitem>
6725
6726 <listitem>
6727 <para>The method IConsole::discardSavedState was renamed to
6728 IConsole::forgetSavedState, and a parameter was added.</para>
6729 </listitem>
6730
6731 <listitem>
6732 <para>The method IConsole::powerDownAsync was renamed to
6733 <link linkend="IConsole__powerDown">IConsole::powerDown</link>,
6734 and the previous method with that name was deleted. So effectively a
6735 parameter was added.</para>
6736 </listitem>
6737
6738 <listitem>
6739 <para>In the
6740 <link linkend="IFramebuffer">IFramebuffer</link> interface, the
6741 following were removed:<itemizedlist>
6742 <listitem>
6743 <para>the <computeroutput>operationSupported</computeroutput>
6744 attribute;</para>
6745
6746 <para>(as a result, the
6747 <computeroutput>FramebufferAccelerationOperation</computeroutput>
6748 enum was no longer needed and removed as well);</para>
6749 </listitem>
6750
6751 <listitem>
6752 <para>the <computeroutput>solidFill()</computeroutput>
6753 method;</para>
6754 </listitem>
6755
6756 <listitem>
6757 <para>the <computeroutput>copyScreenBits()</computeroutput>
6758 method.</para>
6759 </listitem>
6760 </itemizedlist></para>
6761 </listitem>
6762
6763 <listitem>
6764 <para>In the <link linkend="IDisplay">IDisplay</link>
6765 interface, the following were removed:<itemizedlist>
6766 <listitem>
6767 <para>the
6768 <computeroutput>setupInternalFramebuffer()</computeroutput>
6769 method;</para>
6770 </listitem>
6771
6772 <listitem>
6773 <para>the <computeroutput>lockFramebuffer()</computeroutput>
6774 method;</para>
6775 </listitem>
6776
6777 <listitem>
6778 <para>the <computeroutput>unlockFramebuffer()</computeroutput>
6779 method;</para>
6780 </listitem>
6781
6782 <listitem>
6783 <para>the
6784 <computeroutput>registerExternalFramebuffer()</computeroutput>
6785 method.</para>
6786 </listitem>
6787 </itemizedlist></para>
6788 </listitem>
6789 </itemizedlist>
6790 </sect1>
6791
6792 <sect1>
6793 <title>Incompatible API changes with version 2.2</title>
6794
6795 <itemizedlist>
6796 <listitem>
6797 <para>Added explicit version number into JAX-WS Java package names,
6798 such as <computeroutput>org.virtualbox_2_2</computeroutput>,
6799 allowing connect to multiple VirtualBox clients from single Java
6800 application.</para>
6801 </listitem>
6802
6803 <listitem>
6804 <para>The interfaces having a "2" suffix attached to them with
6805 version 2.1 were renamed again to have that suffix removed. This
6806 time around, this change involves only the name, there are no
6807 functional differences.</para>
6808
6809 <para>As a result, IDVDImage2 is now IDVDImage; IHardDisk2 is now
6810 IHardDisk; IHardDisk2Attachment is now IHardDiskAttachment.</para>
6811
6812 <para>Consequentially, all related methods and attributes that had a
6813 "2" suffix have been renamed; for example, IMachine::attachHardDisk2
6814 now becomes IMachine::attachHardDisk().</para>
6815 </listitem>
6816
6817 <listitem>
6818 <para>IVirtualBox::openHardDisk has an extra parameter for opening a
6819 disk read/write or read-only.</para>
6820 </listitem>
6821
6822 <listitem>
6823 <para>The remaining collections were replaced by more performant
6824 safe-arrays. This affects the following collections:</para>
6825
6826 <itemizedlist>
6827 <listitem>
6828 <para>IGuestOSTypeCollection</para>
6829 </listitem>
6830
6831 <listitem>
6832 <para>IHostDVDDriveCollection</para>
6833 </listitem>
6834
6835 <listitem>
6836 <para>IHostFloppyDriveCollection</para>
6837 </listitem>
6838
6839 <listitem>
6840 <para>IHostUSBDeviceCollection</para>
6841 </listitem>
6842
6843 <listitem>
6844 <para>IHostUSBDeviceFilterCollection</para>
6845 </listitem>
6846
6847 <listitem>
6848 <para>IProgressCollection</para>
6849 </listitem>
6850
6851 <listitem>
6852 <para>ISharedFolderCollection</para>
6853 </listitem>
6854
6855 <listitem>
6856 <para>ISnapshotCollection</para>
6857 </listitem>
6858
6859 <listitem>
6860 <para>IUSBDeviceCollection</para>
6861 </listitem>
6862
6863 <listitem>
6864 <para>IUSBDeviceFilterCollection</para>
6865 </listitem>
6866 </itemizedlist>
6867 </listitem>
6868
6869 <listitem>
6870 <para>Since "Host Interface Networking" was renamed to "bridged
6871 networking" and host-only networking was introduced, all associated
6872 interfaces needed renaming as well. In detail:</para>
6873
6874 <itemizedlist>
6875 <listitem>
6876 <para>The HostNetworkInterfaceType enum has been renamed to
6877 <link linkend="HostNetworkInterfaceMediumType">HostNetworkInterfaceMediumType</link></para>
6878 </listitem>
6879
6880 <listitem>
6881 <para>The IHostNetworkInterface::type attribute has been renamed
6882 to
6883 <link linkend="IHostNetworkInterface__mediumType">IHostNetworkInterface::mediumType</link></para>
6884 </listitem>
6885
6886 <listitem>
6887 <para>INetworkAdapter::attachToHostInterface() has been renamed
6888 to INetworkAdapter::attachToBridgedInterface</para>
6889 </listitem>
6890
6891 <listitem>
6892 <para>In the IHost interface, createHostNetworkInterface() has
6893 been renamed to
6894 <link linkend="IHost__createHostOnlyNetworkInterface">createHostOnlyNetworkInterface()</link></para>
6895 </listitem>
6896
6897 <listitem>
6898 <para>Similarly, removeHostNetworkInterface() has been renamed
6899 to
6900 <link linkend="IHost__removeHostOnlyNetworkInterface">removeHostOnlyNetworkInterface()</link></para>
6901 </listitem>
6902 </itemizedlist>
6903 </listitem>
6904 </itemizedlist>
6905 </sect1>
6906
6907 <sect1>
6908 <title>Incompatible API changes with version 2.1</title>
6909
6910 <itemizedlist>
6911 <listitem>
6912 <para>With VirtualBox 2.1, error codes were added to many error
6913 infos that give the caller a machine-readable (numeric) feedback in
6914 addition to the error string that has always been available. This is
6915 an ongoing process, and future versions of this SDK reference will
6916 document the error codes for each method call.</para>
6917 </listitem>
6918
6919 <listitem>
6920 <para>The hard disk and other media interfaces were completely
6921 redesigned. This was necessary to account for the support of VMDK,
6922 VHD and other image types; since backwards compatibility had to be
6923 broken anyway, we seized the moment to redesign the interfaces in a
6924 more logical way.</para>
6925
6926 <itemizedlist>
6927 <listitem>
6928 <para>Previously, the old IHardDisk interface had several
6929 derivatives called IVirtualDiskImage, IVMDKImage, IVHDImage,
6930 IISCSIHardDisk and ICustomHardDisk for the various disk formats
6931 supported by VirtualBox. The new IHardDisk2 interface that comes
6932 with version 2.1 now supports all hard disk image formats
6933 itself.</para>
6934 </listitem>
6935
6936 <listitem>
6937 <para>IHardDiskFormat is a new interface to describe the
6938 available back-ends for hard disk images (e.g. VDI, VMDK, VHD or
6939 iSCSI). The IHardDisk2::format attribute can be used to find out
6940 the back-end that is in use for a particular hard disk image.
6941 ISystemProperties::hardDiskFormats[] contains a list of all
6942 back-ends supported by the system.
6943 <link linkend="ISystemProperties__defaultHardDiskFormat">ISystemProperties::defaultHardDiskFormat</link>
6944 contains the default system format.</para>
6945 </listitem>
6946
6947 <listitem>
6948 <para>In addition, the new
6949 <link linkend="IMedium">IMedium</link> interface is a generic
6950 interface for hard disk, DVD and floppy images that contains the
6951 attributes and methods shared between them. It can be considered
6952 a parent class of the more specific interfaces for those images,
6953 which are now IHardDisk2, IDVDImage2 and IFloppyImage2.</para>
6954
6955 <para>In each case, the "2" versions of these interfaces replace
6956 the earlier versions that did not have the "2" suffix.
6957 Previously, the IDVDImage and IFloppyImage interfaces were
6958 entirely unrelated to IHardDisk.</para>
6959 </listitem>
6960
6961 <listitem>
6962 <para>As a result, all parts of the API that previously
6963 referenced IHardDisk, IDVDImage or IFloppyImage or any of the
6964 old subclasses are gone and will have replacements that use
6965 IHardDisk2, IDVDImage2 and IFloppyImage2; see, for example,
6966 IMachine::attachHardDisk2.</para>
6967 </listitem>
6968
6969 <listitem>
6970 <para>In particular, the IVirtualBox::hardDisks2 array replaces
6971 the earlier IVirtualBox::hardDisks collection.</para>
6972 </listitem>
6973 </itemizedlist>
6974 </listitem>
6975
6976 <listitem>
6977 <para><link linkend="IGuestOSType">IGuestOSType</link> was
6978 extended to group operating systems into families and for 64-bit
6979 support.</para>
6980 </listitem>
6981
6982 <listitem>
6983 <para>The
6984 <link linkend="IHostNetworkInterface">IHostNetworkInterface</link>
6985 interface was completely rewritten to account for the changes in how
6986 Host Interface Networking is now implemented in VirtualBox
6987 2.1.</para>
6988 </listitem>
6989
6990 <listitem>
6991 <para>The IVirtualBox::machines2[] array replaces the former
6992 IVirtualBox::machines collection.</para>
6993 </listitem>
6994
6995 <listitem>
6996 <para>Added
6997 <link linkend="IHost__getProcessorFeature">IHost::getProcessorFeature()</link>
6998 and <link linkend="ProcessorFeature">ProcessorFeature</link>
6999 enumeration.</para>
7000 </listitem>
7001
7002 <listitem>
7003 <para>The parameter list for
7004 <link linkend="IVirtualBox__createMachine">IVirtualBox::createMachine()</link>
7005 was modified.</para>
7006 </listitem>
7007
7008 <listitem>
7009 <para>Added IMachine::pushGuestProperty.</para>
7010 </listitem>
7011
7012 <listitem>
7013 <para>New attributes in IMachine: accelerate3DEnabled,
7014 HWVirtExVPIDEnabled,
7015 <computeroutput>IMachine::guestPropertyNotificationPatterns</computeroutput>,
7016 <link linkend="IMachine__CPUCount">CPUCount</link>.</para>
7017 </listitem>
7018
7019 <listitem>
7020 <para>Added
7021 <link linkend="IConsole__powerUpPaused">IConsole::powerUpPaused()</link>
7022 and
7023 <link linkend="IConsole__getGuestEnteredACPIMode">IConsole::getGuestEnteredACPIMode()</link>.</para>
7024 </listitem>
7025
7026 <listitem>
7027 <para>Removed ResourceUsage enumeration.</para>
7028 </listitem>
7029 </itemizedlist>
7030 </sect1>
7031 </chapter>
7032</book>
7033<!-- vim: set shiftwidth=2 tabstop=2 expandtab: -->
Note: See TracBrowser for help on using the repository browser.

© 2023 Oracle
ContactPrivacy policyTerms of Use