全部工具下载链接
http://download.sysinternals.com/Files/SysinternalsSuite.zip

XBMC Media Center

XBMC Media Center is your ultimate multimedia hub. From the stunning interface, down to
the helpful and enthusiastic community, it has everything you need to take your media
enjoyment experience to the next level. Under the hood lies an extremely powerful and versatile
custom skinning engine which allows skinners to define nearly every aspect of the application
and make their wildest dreams a reality. XBMC's library mode will take that mess of media files
you have collected over the years and present them to you in immaculate organization. It taps
several meta data sources for a plethora of information to enrich your experience. In addition to
media on your computer, XBMC can stream content from a multitude of on-line resources for
your enjoyment. A python interface lets you customize behavior and adds yet another source of
content via scripts and plug-ins. Playback is handled by a pair of in-house players. One for
music and another for video, each leveraging the very best of open source codecs ensuring
XBMC can handle anything you throw at it. These features and many more make XBMC your
best choice in home theater computer software.

Graphical User Interface and Skinning Engine

Dubbed guilib internally, XBMC's skinning engine is one of the most powerful available in the
HTPC market. The XBMC core defines a minimum set of controls for each window to do its
job but the skin is free to present these and any additional controls as they wish. Skin authors
have all of the usual GUI elements at their disposal; labels, buttons, radio buttons, text boxes,
spin boxes, sliders, scroll bars, control lists and control groups are all completely customizable.
In addition, guilib takes advantage of today's 3D graphics hardware to provide silky smooth,
animations and transitions.

Skins are defined by text files formatted in the XML mark-up language and images. There is
one XML file to define each window and dialog defined by the core application. In this file, the
position, dimensions, visibility, images and navigation details of each control are specified, as
well as any animations and transitions for the window. Skins can also add more controls to each

window that execute XBMC built-in functions and scripts, raise specific windows, or query
player and system information. Control visibility can be conditional based on what the
application is doing at the time and can be delayed if need be. There is also the ability for skins
to add their own settings to control aspects of the look.

The skin engine also contains several other parts of the interface. There is a window manager
which keeps track of view states of each window such as list sort orders and currently selected
control. An audio manager plays navigation sounds on cursor movement, click and back
actions. XBMC has been translated to dozens of languages. guilib handles all string
localization and also lets skins declare their own strings with translations. The last
responsibility of guilib is user input, taking events from a remote control, keyboard, mouse or
some other device through an event client and passing them on to the application.

Interfaces

XBMC offers several interfaces to control, modify behavior and add content. The built in
Python interpreter provides two of these interfaces. The first, scripts, are mini programs
designed to stand alone from XBMC. The xbmc and xbmcgui modules define the Python API
into XBMC. Functions for controlling players, querying meta data, manipulating settings and
the like are all available through the xbmc module. Script graphical interfaces are designed
using the xbmcgui module, all of the controls available in the skinning engine can also be used
for scripting. Using the WindowXML class in the xbmcgui module, the script can be skinned in
an identical fashion to XBMC itself. Scripts can perform their task in the background with no
user interactivity at all, or obtain a fully customizable window for a clean graphical interface.

The Python interpreter also provides file system (or directory) plug-ins, commonly referred to
simply as “plugins”. These are special python scripts designed to fill a directory listing with
content which may not be easily described otherwise and fit it in to the normal categories
provided by XBMC (music, video, pictures and programs). Plug-ins take their visual queues

from the active XBMC skin so no specific skinning is necessary or available. They can also add
items to the XBMC context menu when the plug-in is active, as well as define their own
settings. File system plug-ins are often used to integrate content from websites (eg. YouTube)
into XBMC.

Remote access to XBMC is provided via an embedded web server. It serves a web page
offering the ability to browse your media and control the XBMC session from your web
browser. The web server also provides the XBMC HTTP-API for developers to add XBMC
control to their applications. It exposes full control over XBMC as well as information
regarding what is currently playing and querying the library databases. Commands are
executed by making a simple HTTP GET request and any information or status codes are
returned in HTML format. Adding new functions to this interface is very simple in the XBMC
code base.

A recently added interface into XBMC is the Event Server. The aim of this API is to allow
developers to add support for various types of input devices. It listens on a UDP socket for
Event Clients to connect and send events. The clients run separately from XBMC and can be
written in any programming language that supports UDP networking. They commonly leverage
other libraries written to handle the target input device. Their main interaction is sending button
presses or joystick action to XBMC, but can also send notification messages for events such as
battery status. One popular event client adds support for the Sony Playstation 3 bluetooth six
axis game pad.

There are two new APIs currently in development branches of XBMC. The first, DLL Add-ons,
aims to add features similar to the Python interpreter. The difference will be that the
applications will be written in C or C++ and compiled into modules, removing the python
interpreter overhead. XBMC can then load and execute them at the user's request. Secondly,
PVR Clients, will allow interaction with PVR back end applications such as MythTV and VDR.
This will give XBMC OTA, DVB, etc card access without having to actually support any

hardware itself. When completed, users will be able to fully control features of supported PVR
applications, including; live TV, record timers, time shifting and on-screen guides.

Content Management

In order for content to be visible in XBMC a source must be created to point to it. There are
several available sources for media content supported out of box. Locally, any content on the
users hard disk, CD-ROM or DVD-ROM can be added. Remote sources, though, are where
XBMC really gets interesting. Users can point XBMC at another computer serving their media
via SMB (Windows File Sharing), HTTP, FTP, UPnP and DAAP (iTunes 6 sharing).
Additionally sources for some service can be configured without support software such as
Last.fm and shoutcast radio streams and OTA/DVB TV devices, such as dbox, tuxbox and
MythTV live TV, which export the video stream over the local network.

Once a source is added, all of its contents is immediately available via the file view. This view
presents media as you would expect in a file browser, with an icon, the file name, and a few
other details pertinent to the selected sort order. If source contains static data (ie. the media isn't
a stream), it can now be scanned into the library. This involves selecting a content type for
videos; one of TV, Movies or Music Videos, selecting a website to scrape meta data from and
answering a few questions as to how the files are laid out. XBMC will now read any tags and
hunt out meta data on-line, storing this information in a database for quick easy access, later.

Library view is now available, providing a far richer experience. Fanart (backgrounds that
relate to the focused media item) will be displayed in some view modes. In the music section,
artist biographies and album reviews are available. For videos, you can now see play times, air
dates, ratings, season and episode numbers, actors and a multitude of other information. This
meta data is then used to organize media files and present them to in a friendly fashion.
Another nice feature of the library is smart play lists. These are automatically generate play
lists based on user selected values of meta data fields.

Player Core

Playback quality is paramount to XBMC's success. To that end, a pair of custom players are
employed to ensure the utmost performance. DVDPlayer is used for all video playback. It is
based off of the FFMpeg multimedia decoding library and features playback of all popular
audio and video codecs, several subtitle formats as well as DVD menu support. Music playback
is handled by PAPlayer. It takes advantage of several open source audio codecs and features
gap-less playback and cross-fade. There is even a special codec that calls in to DVDPlayer on
the off chance that PAPlayer doesn't recognize a file type. PAPlayer also has a facility to export
the raw audio samples supporting reactive visualizations.

File Sharing

XBMC provides local network file sharing via a UPnP server. It relies on the library features,
and allows for the content and meta-data in the library to be provided to other UPnP clients on
your network. The server strives to be DLNA compliant, so it will work with popular clients
such as Windows Media Player, Xbox360 and Playstation3 assuming they support the format
being requested.

 

#include <iostream> 

int main() 
{     
    int i=3;
    std::wcout.imbue(std::locale("chs"));
    wchar_t wPortName[13] = L"\\\\.\\COM"; 
    wchar_t wPortNum[3];
    _itow(i,wPortNum,10);
    wcscat(wPortName,wPortNum);
    std::wcout <<wPortName<< std::endl;
    std::wcin>>wPortName;
    return 0;
} 

 输出、连接字符串、整型转字符串

     However, before we begin to explorer the new functions, we must lay the foundation by
understanding the rudiments of resolving hosts, protocols, and services. With that background,
you weill be prepared to master the more complex Winsock 2 resolution functions. Therefore,
we'll concentrate on winsock 1.1 resolution functions in this chapter and leave the Winsok 2
 protocol-indenpent functions to the next chapter. Before dealing with the Winsock 1.1 resolution
 functions in detail, we'll examine the translation functions that handle byte ordering.

     Before dipping (浸渍) our toes (脚趾) in the unknown waters of Winsock resolution, let's consider
this question: What is Winsock 1.1 resolution(解析) ? We'll use a simple analogy(模拟) to discover
an answer to this question. You use a telephone directory to look up a telephone number to call your firend.
The telephone directory enables   you to quickly retrieve your firend's telephone number without having to
remember the number. When it comes to host name resolution, the same princi-
ple applies. when you want to connect with a host on the Internet, you need to
know its IP address, which, if you like, is the equivalent of the telephone num-
ber. Hosts on every TCP/IP network, including the Internet, use IP addresses
to identify themselves to each other. Unfortunately, the majority of humans (and
that includes Delphi developers) cannot remember IP addresses in their raw
form. In the early days of the Internet, IP addresses were routinely used but
became impossible when the Internet expanded. To resolve (no pun intended)
this problem, the mechanism of mapping names (essentially aliases) to IP
address came into being. The mapping of these aliases to their IP address is
called host name resolution. Because of mapping names that are user friendly,
that is, easy to remember, you don't need to know the host's IP address, pro-
videdk you know its friendly name.
  Establishing a mapping of a host name with an IP address is not the end of
the equation. Before you can communicate with a TCP/IP host, you need to
know the port upon which the host operates the desired service, like FTP and
HTTP. Extending the telephone directory analogym, you would either know your
firend's extension or speak with the operator to put you through to your friend.
Perhaps in your case, you would speak to the operator to get though. This is
analogous to what we call service resolution. Added to this equation, we must
also resolve service names to their port numbers. Services such as FTP and
HTTP are well known to surfers on the Net, but hosts deal in numbers when it
comes to providing a service like FTP. Again, service names were invented to
make life easier for users. Like host name mapping, it is necessary to map
human understandable service names to their ports, which are numbers that
hosts can understand.
  And that's not all. We also need to resolve transport protocols to their proto-
col numbers. Hosts require knowning which transport protocols are needed to
operate a service. For example, FTP reauires the TCP protocol, which hosts
translate as 6. We will continue to use the telephone directory analogy as we
examine the Winsock 1.1 resolution functions.

Translation Function
  Computers store numbers through byte ordering. There are two ways to repre-
sent numbers, little endian and big endian. Intel processors store numbers in
little endian format-from the least significant byte to the most significant byte
(right to left). On other processors (such as those that run some UNIX sys-
tems), numbers are in big-endian format-from the mostsignificant byte to the
least significant byte-left to right. Since the Internet is a heterogeneous net-
work of different computers, incompatible byte ordering poses a significant
obstacle to communication. To overcome this barrier, current network standards
specify that ports used for communicating between computers should be in net-
work byte order ( otherwise known as big endian format), irrespective of their
native byte ordering. That is, network byte order is big endian for use on the
TCP/IP network. You mustn't forget that network address, datagram length,
and TCP/IP window sizes must also be in network byte order (big endian).
  Figure 3-1 on the following page shows how little endian and big endian num-
bers are stored in memory.
  So, before using resolution functions and starting communications, your
application needs to translate the native host byte (little endian) ordered num-
ber (for example, port number of the host on the PC) to network byte ordered
number first. That is, you must translate the prot number into network byte
order. If this translation is not done, it is very likely that connecting with the
service on the host will never occur, even if the host name resolution works.
Another problem that can cause you to scratch your head is using the port in
host byte order instead of network byte order, which is a common lapse. How-
ever, it is not necessary to convert numberical data into network byte order; only
prot numbers, services, and IP addresses need to be in network byte order.
  The following trivial example shows graphically the effect of converting a
number in host byte order to network byte order and from network byte order
to host byte order:
host: 100d->00000064h
network:64000000h=1677721600d

  The following functions are used to convert from host byte order to network
byte order, or network byte order to host byte order.

function htonl Winsock2.pas
Syntax
  htonl(hostlong:u_long):u_long;stdcall;
Description
  This function translates a 32-bit integer from host byte order to network byte
  order. In other words, it translates an integer in little endian format to big
  endian format.
Parameters
  hostlong: A 32-bit integer in host byte order
Return Value
  The function will return a value in network byte order.
See Also
  htons, ntohl, ntohs, WSAHtonl, WSAHtons, WSANtohl, WSANtohs
Example
  See Listing 3-1 (program EX31).

function htons Winsock2.pas
Syntax
  htos(hostshort:u_short):u_short;stdcall;
Description
  This function translates a 16-bit integer from host byte order to network byte
  order. In other words, it translates an integer in little endian format to big
  endian format.
Parameters
  hostshort: A 16-bit number in host byte order
Return Value
  The function will return a value in network byte order
See Also
  htonl, ntohl, WSAHtonl, WSAHtons, WSANtohl, WSANtohs
Example
  See Listing 3-1 (program EX31).

function ntohl Winsock2.pas
Syntax
  ntohl(netlong:u_long):u_long;stdcall;
Description
  This function converts a 32-bit integer form network byte order to host byte
  order. In other words, it translates an integer in big endian format to little
  endian format.
Parameters
  netlong: A 32-bit integer in network byte order
Return Value
  The function will return a value in host byte order.
See Also
  htonl, htons, ntohs, WSAHtonl, WSAHtons, WSANtohl, WSANtohs
Example
  See Listing 3-1 (program EX31).

function ntohs Winsock2.pas
Syntax
  ntohs(netlong:u_short):u_short;stdcall;
Description
  This function converts a 32-bit integer form network byte order to host byte
  order. In other words, it translates an integer in big endian format to little
  endian format.
Parameters
  netlong: A 32-bit integer in network byte order
Return Value
  The function will return a value in host byte order.
See Also
  htonl, htons, ntohs, WSAHtonl, WSAHtons, WSANtohl, WSANtohs
Example
  See Listing 3-1 (program EX31).