1 :template: standard_nacl_api 2 3 ############################ 4 Debugging With Visual Studio 5 ############################ 6 7 8 .. contents:: Table Of Contents 9 :local: 10 :backlinks: none 11 :depth: 2 12 13 Whether you're porting an existing project or starting from scratch, the Native 14 Client Visual Studio add-in makes it easier to set up, build, run and debug 15 your Native Client app by integrating the Native Client SDK development tools 16 into the Visual Studio environment. 17 18 .. Note:: 19 :class: note 20 21 The Native Client add-in requires Visual Studio 2010 with Service Pack 1. No 22 other versions of Visual Studio are currently supported. Visual Studio 23 Express is also not supported. 24 25 Introduction 26 ============ 27 28 The Native Client add-in for Visual Studio helps you develop your application 29 more efficiently in many ways: 30 31 * Organize and maintain your code as a Visual Studio project. 32 * Iteratively write and test your application more easily. Visual Studio 33 handles the details of launching a web server to serve your module and run 34 the module in Chrome with a debugger attached. 35 * Compile your module into a dynamically-linked library (DLL) using Visual 36 Studio's C/C++ compiler and run it as a Pepper plugin. This allows you to 37 develop code incrementally, coding and/or porting one feature at a time into 38 the Pepper APIs while continuing to use native Windows APIs that would 39 otherwise be unavailable in an actual Native Client module. 40 * Use Visual Studio's built-in debugger to debug your code while its running 41 as a Pepper plugin. 42 * Compile your module into a .nexe or .pexe file using the Native Client SDK 43 tools and run it as a bona fide Native Client module. 44 * Use the Native Client debugger, nacl-gdb, to test your code when its running 45 as a Native Client object. 46 47 The add-in defines five new Visual Studio platforms: ``PPAPI``, ``NaCl32``, 48 ``NaCl64``, ``NaClARM``, and ``PNaCl``. These platforms can be applied to the 49 debug configuration of solutions and projects. The platforms configure the 50 properties of your project so it can be built and run as either a Pepper plugin 51 or a Native Client module. The platforms also define the behavior associated 52 with the debug command so you can test your code while running in Visual 53 Studio. 54 55 Platforms 56 ========= 57 58 It is helpful to consider the Visual Studio add-in platforms in two groups. One 59 contains the PPAPI platform only. The other group, which we'll call the Native 60 Client platforms, contains platforms that all have "NaCl" in their names: 61 ``NaCl32``, ``NaCl64``, ``NaClARM``, and ``PNaCl``. The diagram below shows the 62 platforms, the ways they are normally used, and the build products they produce. 63 64 .. image:: /images/visualstudio4.png 65 66 Using platforms, your workflow is faster and more efficient. You can compile, 67 start, and debug your code with one click or key-press. When you press F5, the 68 start debugging command, Visual Studio automatically launches a web server to 69 serve your module (if necessary) along with an instance of Chrome that runs 70 your Native Client module, and also attaches an appropriate debugger. 71 72 You can switch between platforms as you work to compare the behavior of your 73 code. 74 75 When you run your project, Visual Studio launches the PPAPI and Native Client 76 platforms in different ways, as explained in the next sections. 77 78 The PPAPI platform 79 ------------------ 80 81 The PPAPI platform builds your module as a dynamic library and launches a 82 version of Chrome thats configured to run the library as a plugin when it 83 encounters an ``<embed>`` element with ``type=application/x-nacl`` (ignoring 84 the information in the manifest file). When running in the PPAPI platform, you 85 can use Windows system calls that are unavailable in a regular Native Client 86 module built and running as a .nexe file. This offers the ability to port 87 existing code incrementally, rewriting functions using the PPAPI interfaces one 88 piece at a time. Since the module is built with Visual Studios native compiler 89 (MSBuild) you can use the Visual Studio debugger to control and inspect your 90 code. 91 92 The Native Client platforms 93 --------------------------- 94 95 There are four Native Client platforms. All of them can be used to build Native 96 Client modules. When you run one of the Native Client platforms Visual Studio 97 builds the corresponding type of Native Client module (either a .nexe or 98 .pexe), starts a web server to serve it up, and launches a copy of Chrome that 99 fetches the module from the server and runs it. Visual Studio will also open a 100 terminal window, launch an instance of nacl-gdb, and attach it to your module's 101 process so you can use gdb commands to debug. 102 103 NaCl32 and NaCl64 104 ^^^^^^^^^^^^^^^^^ 105 106 The platforms named NaCl32 and NaCl64 are targeted at x86 32-bit and 64-bit 107 systems respectively. You need both platforms to build a full set of .nexe 108 files when you are ready to distribute your application. Note, however, that 109 when you are testing in Visual Studio you must select the NaCl64 platform 110 (because Chrome for Windows runs Native Client in a 64-bit process). If you try 111 to run from the NaCl32 platform you will get an error message. 112 113 NaClARM 114 ^^^^^^^ 115 116 The NaClARM platform is targeted at ARM-based processors. You can build .nexe 117 files with the NaClARM platform in Visual Studio but you cannot run them from 118 there. You can use Visual Studio to create a Native Client module that includes 119 an ARM-based .nexe file and then run the module from a Chrome browser on an ARM 120 device, such as one of the newer Chromebook computers. See the instructions at 121 :doc:`Running Native Client Applications <running>` for more information on 122 testing your module in Chrome. 123 124 .. Note:: 125 :class: note 126 127 Note: The NaClARM platform currently supports the newlib toolchain only. 128 129 PNaCl 130 ^^^^^ 131 132 The PNaCl (portable NaCl) platform is included in the Visual Studio Native 133 Client add-in versions 1.1 and higher. It supports the .pexe file format. A 134 .pexe file encodes your application as bitcode for a low level virtual machine 135 (LLVM). When you deliver a Native Client application as a PNaCl module, the 136 manifest file will contain a single .pexe file rather than multiple .nexe 137 files. The Chrome client transforms the LLVM bitcode into machine instructions 138 for the local system. 139 140 When you run the PNaCl platform from Visual Studio, Visual Studio uses the 141 Native Client SDK to transform the .pexe file into a NaCl64 .nexe file and runs 142 it as if you were working with a NaCl64 platform. 143 144 .. Note:: 145 :class: note 146 147 Note: The PNaCl platform currently supports the newlib toolchain only. 148 149 Installing the add-in 150 ===================== 151 152 In order to use the Native Client Visual Studio add-in, your development 153 environment should include: 154 155 * A 64-bit version of Windows Vista or Windows 7. 156 * Visual Studio 2010 with Service Pack 1. 157 * `Chrome <https://www.google.com/intl/en/chrome/browser/>`_ version 23 or 158 greater. You can choose to develop using the latest `canary 159 <https://www.google.com/intl/en/chrome/browser/canary.html>`_ build of 160 Chrome, running the canary version side-by-side with (and separately from) 161 your regular version of Chrome. 162 * :doc:`The Native Client SDK <../../sdk/download>` with the ``pepper_23`` 163 bundle or greater. The version of Chrome that you use must be equal or 164 greater than the version of the SDK bundle. 165 166 Set environment variables 167 ------------------------- 168 169 Before you run the installer you must define two Windows environment variables. 170 They point to the bundle in the Native Client SDK that you use to build your 171 module, and to the Chrome browser that you choose to use for debugging. 172 173 To set environment variables in Windows 7, go to the Start menu and search for 174 "environment." One of the links in the results is "Edit environment variables 175 for your account." (You can also reach this link from the ``Control Panel`` 176 under ``User Accounts``.) Click on the link and use the buttons in the window 177 to create or change these user variables (the values shown below are only for 178 example): 179 180 181 +-------------------+----------------------------------------------------------+ 182 | Variable Name | Description | 183 +===================+==========================================================+ 184 | NACL_SDK_ROOT | The path to the pepper directory in the SDK. | 185 | | For example: ``C:\nacl_sdk\pepper_23`` | 186 +-------------------+----------------------------------------------------------+ 187 | CHROME_PATH | The path to the .exe file for the version of Chrome you | 188 | | are testing with. For example: | 189 | | ``C:\Users\fred\AppData\Local\Google\Chrome | 190 | | SxS\Application\chrome.exe`` | 191 +-------------------+----------------------------------------------------------+ 192 193 194 195 Download the add-in 196 ------------------- 197 198 The Native Client Visual Studio add-in is a separate bundle in the SDK named 199 ``vs_addin``. Open a command prompt window, go to the top-level SDK directory, 200 and run the update command, specifying the add-in bundle:: 201 202 naclsdk update vs_addin 203 204 This creates a folder named ``vs_addin``, containing the add-in itself, its 205 installer files, and a directory of examples. 206 207 .. Note:: 208 :class: note 209 210 Note: The vs_addin bundle is only visible when you run ``naclsdk`` on a 211 Windows system. 212 213 Run the installer 214 ----------------- 215 216 The installer script is located inside the ``vs_addin`` folder in the SDK. 217 Right click on the file ``install.bat`` and run it as administrator. 218 219 The script always installs the NativeClient platforms, and asks you if youd 220 like to install the PPAPI platform as well. You can skip the PPAPI step and run 221 the installer again later to add the PPAPI platform. 222 223 You can usually run the installer successfully with no arguments. The new 224 platforms are installed in ``C:\Program Files 225 (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms``. 226 227 In some cases system resources may not be in their default locations. You might 228 need to use these command line arguments when you run ``install.bat``: 229 230 * The MSBuild folder is assumed to be at ``C:\Program Files (x86)\MSBuild``. 231 You can specify an alternate path with the flag ``--ms-build-path=<path>``. 232 The installer assumes Visual Studio has created a user folder at 233 * ``%USERPROFILE%\My Documents\Visual Studio 2010``. You can specify an 234 alternate path with the flag ``--vsuser-path=path``. 235 236 From time to time an update to the Visual Studio add-in may become available. 237 Updates are performed just like an installation. Download the new add-in using 238 naclsdk update and run ``install.bat`` as administrator. 239 240 To uninstall the add-in, run ``install.bat`` as administrator and add the 241 ``--uninstall`` flag. You'll need to run the Command Prompt program as 242 administrator in order to add the flag. Go the to the Windows start menu, 243 search for "Command Prompt," right click on the program and run it as 244 administrator. 245 246 You can verify that the add-in has been installed and determine its version by 247 selecting Add-in Manager in the Visual Studio Tools menu. If the add-in has 248 been installed it will appear in the list of available add-ins. Select it and 249 read its description. 250 251 Try the ``hello_world_gles`` sample project 252 =========================================== 253 254 The add-in comes with an examples directory. Open the sample project 255 ``examples\hello_world_gles\hello_world_gles.sln``. This project is an 256 application that displays a spinning cube. 257 258 Select the NaCl64 platform 259 -------------------------- 260 261 Open the sample project in Visual Studio, select the ``Configuration Manager``, 262 and confirm that the active solution configuration is ``Debug`` and the active 263 project platform is ``NaCl64``. Note that the platform for the 264 ``hello_world_gles`` project is also ``NaCl64``. (You can get to the 265 ``Configuration Manager`` from the ``Build`` menu or the projects 266 ``Properties`` window.) 267 268 .. image:: /images/visualstudio1.png 269 270 Build and run the project 271 ------------------------- 272 273 Use the debugging command (F5) to build and run the project. As the wheels 274 start to turn, you may be presented with one or more alerts. They are benign; 275 you can accept them and set options to ignore them when thats possible. Some 276 of the messages you might see include: 277 278 * "This project is out of date, would you like to build it?" 279 * "Please specify the name of the executable file to be used for the debug 280 session." This should be the value of the environment variable CHROME_PATH, 281 which is usually supplied as the default value in the dialog. 282 * "Debugging information for chrome.exe cannot be found." This is to be 283 expected, you are debugging your module's code, not Chrome. 284 * "Open file - security warning. The publisher could not be verified." If 285 Visual Studio is complaining about x86_64-nacl-gdb.exe, thats our debugger. 286 Let it be. 287 288 Once youve passed these hurdles, the application starts to run and youll see 289 activity in three places: 290 291 #. A terminal window opens running ``nacl-gdb``. 292 #. Chrome launches running your module in a tab. 293 #. The Visual Studio output window displays debugging messages when you select 294 the debug output item. 295 Stop the debugging session by closing the Chrome window, or select the stop 296 debugging command from the debug menu. The nacl-gdb window will close when 297 you stop running the program. 298 299 Test the nacl-gdb debugger 300 -------------------------- 301 302 Add a breakpoint at the SwapBuffers call in the function MainLoop, which is in 303 hello_world.cc. 304 305 .. image:: /images/visualstudio2.png 306 307 Start the debugger again (F5). This time the existing breakpoint is loaded into 308 nacl-gcb and the program will pause there. Type c to continue running. You can 309 use gdb commands to set more breakpoints and step through the application. For 310 details, see :ref:`Debugging with nacl-gdb <using_gdb>` (scroll down to the end 311 of the section to see some commonly used gdb commands). 312 313 Test the Visual Studio debugger 314 ------------------------------- 315 316 If youve installed the ``PPAPI`` platform, go back to the ``Configuration 317 Manager`` and select the ``PPAPI`` platform. This time when Chrome launches the 318 ``nacl-gdb`` window will not appear; the Visual Studio debugger is fully 319 engaged and on the job. 320 321 Inspect the platform properties 322 ------------------------------- 323 324 At this point, it may be helpful to take a look at the properties that are 325 associated with the PPAPI and Native Client platforms---see the settings in the 326 sample project as an example. 327 328 Developing for Native Client in Visual Studio 329 ============================================= 330 331 After youve installed the add-in and tried the sample project, youre ready to 332 start working with your own code. You can reuse the sample project and the 333 PPAPI and Native Client platforms it already has by replacing the source code 334 with your own. More likely, you will add the platforms to an existing project, 335 or to a new project that you create from scratch. 336 337 Adding platforms to a project 338 ----------------------------- 339 340 Follow these steps to add the Native Client and PPAPI platforms to a project: 341 342 #. Open the Configuration Manager. 343 #. On the row corresponding to your project, click the Platform column dropdown 344 menu and select ``<New...>``. 345 #. Select ``PPAPI``, ``NaCl32``, ``NaCl64``, or ``PNaCl`` from the New platform 346 menu. 347 #. In most cases, you should select ``<Empty>`` in the Copy settings from 348 menu. **Never copy settings between ``PPAPI``, ``NaCl32``, ``NaCl64``, 349 ``NaClARM``, or ``PNaCl`` platforms**. You can copy settings from a Win32 350 platform, if one exists, but afterwards be sure that the project properties 351 are properly set for the new platform, as mentioned in step 6 below. 352 #. If you like, check the Create new solutions platform box to create a 353 solution platform in addition to a project platform. (This is optional, but 354 it can be convenient since it lets you switch project platforms from the 355 Visual Studio main window by selecting the solution platform that has the 356 same name.) 357 #. Review the project properties for the new platform you just added. In most 358 cases, the default properties for each platform should be correct, but it 359 pays to check. Be especially careful about custom properties you may have 360 set beforehand, or copied from a Win32 platform. Also confirm that the 361 Configuration type is correct: 362 363 * ``Dynamic Library`` for ``PPAPI`` 364 * ``Application (.pexe)`` for ``PNaCl`` 365 * ``Application (.nexe)`` for ``NaCl32``, ``NaCl64``, and ``NaClARM`` 366 367 Selecting a toolchain 368 --------------------- 369 370 When you build a Native Client module directly from the SDK you can use two 371 different toolchains, newlib or glibc. See :doc:`Dynamic Linking and Loading 372 with glibc <dynamic-loading>` for a description of the two toolchains and 373 instructions on how to build and deploy an application with the glibc 374 toolchain. The Native Client platforms offer you the same toolchain choice. You 375 can specify which toolchain to use in the project properties, under 376 ``Configuration Properties > General > Native Client > Toolchain``. 377 378 .. Note:: 379 :class: note 380 381 Currently, the NaClARM and PNaCl platforms only support the newlib toolchain. 382 383 There is no toolchain property for the PPAPI platform. The PPAPI platform uses 384 the toolchain and libraries that come with Visual Studio. 385 386 Adding libraries to a project 387 ----------------------------- 388 389 If your Native Client application requires libraries that are not included in 390 the SDK you must add them to the project properties (under ``Configuration 391 Properties > Linker > Input > Additional Dependencies``), just like any other 392 Visual Studio project. This list of dependencies is a semi-colon delimited 393 list. On the PPAPI platform the library names include the .lib extension (e.g., 394 ``ppapi_cpp.lib;ppapi.lib``). On the Native Client platforms the extension is 395 excluded (e.g., ``ppapi_cpp;ppapi``). 396 397 Running a web server 398 -------------------- 399 400 In order for the Visual Studio add-in to test your Native Client module, you 401 must serve the module from a web server. There are two options: 402 403 Running your own server 404 ^^^^^^^^^^^^^^^^^^^^^^^ 405 406 When you start a debug run Visual Studio launches Chrome and tries to connect 407 to the web server at the address found in the Chrome command arguments (see the 408 projects Debugging > Command configuration property), which is usually 409 ``localhost:$(NaClWebServerPort)``. If you are using your own server be sure to 410 specify its address in the command arguments property, and confirm that your 411 server is running before starting a debug session. Also be certain that the 412 server has all the files it needs to deliver a Native Client module (see 413 Keeping track of all the pieces, below). 414 415 Running the SDK server 416 ^^^^^^^^^^^^^^^^^^^^^^ 417 418 If there is no web server running at the specified port, Visual Studio will try 419 to launch the simple Python web server that comes with the Native Client SDK. 420 It looks for a copy of the server in the SDK itself (at 421 ``%NACL_SDK_ROOT%\tools\httpd.py``), and in the project directory 422 (``$(ProjectDir)/httpd.py``). If the server exists in one of those locations, 423 Visual Studio launches the server. The server output appears in Visual Studios 424 Output window, in the pane named Native Client Web Server Output. A server 425 launched in this way is terminated when the debugging session ends. 426 427 Keeping track of all the pieces 428 ------------------------------- 429 430 No matter where the web server lives or how its launched you must make sure 431 that it has all the files that your application needs: 432 433 * All Native Client applications must have an :ref:`html host page 434 <html_file>`. This file is typically called ``index.html``. The host page 435 must have an embed tag with its type attribute set to 436 ``application-type/x-nacl``. If you plan to use a Native Client platform the 437 embed tag must also include a src attribute pointing to a Native Client 438 manifest (.mnf) file. 439 * If you are using a Native Client platform you must include a valid 440 :ref:`manifest file <manifest_file>`. The manifest file points to the .pexe 441 or .nexe files that Visual Studio builds. These will be placed in the 442 directory specified in the projects ``General > Output Directory`` 443 configuration property, which is usually ``$(ProjectDir)$(ToolchainName)``. 444 Visual Studio can use the Native Client SDK script create_nmf.py to 445 automatically generate the manifest file for you. To use this script set the 446 project's ``Linker > General > Create NMF Automatically`` property to "yes." 447 448 If you are letting Visual Studio discover and run the SDK server, these files 449 should be placed in the project directory. If you are running your own server, 450 you must be sure that the host page ``index.html`` is placed in your servers 451 root directory. Remember, if youre using one of the Native Client platforms 452 the paths for the manifest file and .pexe or .nexe files must be reachable from 453 the server. 454 455 The structure of the manifest file can be more complicated if your application 456 uses Native Client's ability to dynamically link libraries. You may have to add 457 additional information about dynamically linked libraries to the manifest file 458 even if you create it automatically. The use and limitations of the create_nmf 459 tool are explained in :ref:`Generating a Native Client manifest file for a 460 dynamically linked application <dynamic_loading_manifest>`. 461 462 You can look at the example projects in the SDK to see how the index and 463 manifest files are organized. The example project ``hello_nacl`` has a 464 subdirectory also called ``hello_nacl``. That folder contains ``index.html`` 465 and ``hello_nacl.nmf``. The nexe file is found in 466 ``NaCl64\newlib\Debug\hello_nacl_64.nexe``. The ``hello_world_gles`` example 467 project contains a subdirectory called `hello_world_gles``. That directory 468 contains html files built with both toolchains (``index_glibc.html`` and 469 ``index_newlib.html``). The .nexe and .nmf files are found in the newlib and 470 glibc subfolders. For additional information about the parts of a Native Client 471 application, see :doc:`Application Structure 472 <../coding/application-structure>`. 473 474 Using the debuggers 475 ------------------- 476 477 PPAPI plugins are built natively by Visual Studios compiler (MSBuild), and 478 work with Visual Studios debugger in the usual way. You can set breakpoints in 479 the Visual Studio source code files before you begin debugging, and on-the-fly 480 while running the program. 481 482 NaCl32 and NaClARM executables (.nexe files) cannot be run or debugged from 483 Visual Studio. 484 485 NaCl64 executables (.nexe files) are compiled using one of the Native Client 486 toolchains in the SDK, which create an `ELF-formatted 487 <`http://en.wikipedia.org/wiki/Executable_and_Linkable_Format>`_ executable. To 488 debug a running .nexe you must use nacl-gdb, which is a command line debugger 489 that is not directly integrated with Visual Studio. When you start a debugging 490 session running from a NaCl64 platform, Visual Studio automatically launches 491 nacl-gdb for you and attaches it to the nexe. Breakpoints that you set in 492 Visual Studio before you start debugging are transferred to nacl-gdb 493 automatically. During a NaCl debugging session you can only use nacl-gdb 494 commands. 495 496 The PNaCl platform generates a .pexe file. When you run the debugger add-in 497 translates the .pexe file to a .nexe file and runs the resulting binary with 498 nacl-gdb attached. 499 500 For additional information about nacl-gdb, see :ref:`Debugging with nacl-gdb 501 <using_gdb>` (scroll down to the end of the section to see some commonly used 502 gdb commands). 503 504 Note that you cant use the Start Without Debugging command (Ctrl+F5) with a 505 project in the Debug configuration. If you do, Chrome will hang because the 506 Debug platform launches Chrome with the command argument 507 ``--wait-for-debugger-children`` (in PPAPI) or ``--enable-nacl-debug`` (in a 508 Native Client platform). These flags cause Chrome to pause and wait for a 509 debugger to attach. If you use the Start Without Debugging command, no debugger 510 attaches and Chrome just waits patiently. To use Start Without Debugging, 511 switch to the Release configuration, or manually remove the offending argument 512 from the ``Command Arguments`` property. 513 514 Disable Chrome caching 515 ---------------------- 516 517 When you debug with a Native Client platform you might want to :ref:`disable 518 Chrome's cache <cache>` to be sure you are testing your latest and greatest 519 code. 520 521 A warning about PostMessage 522 --------------------------- 523 524 Some Windows libraries define the symbol ``PostMessage`` as ``PostMessageW``. 525 This can cause havoc if you are working with the PPAPI platform and you use the 526 Pepper ``PostMessage()`` call in your module. Some Pepper API header files 527 contain a self-defensive fix that you might need yourself, while you are 528 testing on the PPAPI platform. Here it is: 529 530 .. naclcode:: 531 532 // If Windows defines PostMessage, undef it. 533 #ifdef PostMessage 534 #undef PostMessage 535 #endif 536 537 Porting Windows applications to Native Client in Visual Studio 538 -------------------------------------------------------------- 539 540 At Google I/O 2012 we demonstrated how to port a Windows desktop application to 541 Native Client in 60 minutes. The `video 542 <http://www.youtube.com/watch?v=1zvhs5FR0X8&feature=plcp>`_ is available to 543 watch on YouTube. The ``vs_addin/examples`` folder contains a pair of simple 544 examples that demonstrate porting process. They are designed to be completed 545 in just 5 minutes. The two examples are called ``hello_nacl`` and 546 ``hello_nacl_cpp``. They are essentially the same, but the former uses the C 547 PPAPI interface while the latter uses the C++ API. The application is the 548 familiar "Hello, World." 549 550 Each example begins with the Windows desktop version running in the ``Win32`` 551 platform. From there you move to the ``PPAPI`` platform, where you perform a 552 series of steps to set up the Native Client framework, use it to run the 553 desktop version, and then port the behavior from Windows calls to the PPAPI 554 interface. You wind up with a program that uses no Windows functions, which 555 can run in either the ``PPAPI`` or the ``NaCl64`` platform. 556 557 The example projects use a single source file (``hello_nacl.c`` or 558 ``hello_nacl_cpp.cpp``). Each step in the porting process is accomplished by 559 progressively defining the symbols STEP1 through STEP6 in the source. Inline 560 comments explain how each successive step changes the code. View the example 561 code to see how it's actually done. Here is a summary of the process: 562 563 Win32 Platform 564 ^^^^^^^^^^^^^^ 565 566 STEP1 Run the desktop application 567 Begin by running the original Windows application in the Win32 platform. 568 569 PPAPI Platform 570 ^^^^^^^^^^^^^^ 571 572 STEP2 Launch Chrome with an empty Native Client module 573 Switch to the PPAPI platform and include the code required to initialize a 574 Native Module instance. The code is bare-boned, it does nothing but 575 initialize the module. This step illustrates how Visual Studio handles all 576 the details of launching a web-server and Chrome, and running the Native 577 Client module as a Pepper plugin. 578 579 STEP3 Run the desktop application synchronously from the Native Client module 580 The Native Client creates the window directly and then calls WndProc to run 581 the desktop application. Since WndProc spins in its message loop, the call to 582 initialize the module never returns. Close the Hello World window and the 583 module initialization will finish. 584 585 STEP4 Running the desktop application and Native Client asynchronously 586 In WndProc replace the message loop with a callback function. Now the app 587 window and the Native Client module are running concurrently. 588 589 STEP5 Redirect output to the web page 590 The module initialization code calls initInstanceInBrowserWindow rather than 591 initInstanceInPCWindow. WndProc is no longer used. Instead, postMessage is 592 called to place text (now "Hello, Native Client") in the web page rather than 593 opening and writing to a window. Once you've reached this step you can start 594 porting pieces of the application one feature at a time. 595 596 STEP6 Remove all the Windows code 597 All the Windows code is def'd out, proving we are PPAPI-compliant. The 598 functional code that is running is the same as STEP5. 599 600 NaCl64 Platform 601 ^^^^^^^^^^^^^^^ 602 603 Run the Native Client Module in the NaCl64 platform 604 You are still running the STEP6 code, but as a Native Client module rather 605 than a Pepper plugin. 606 607 .. TODO(sbc): port reference section? 608