网站公告列表

  没有公告

加入收藏
设为首页
联系站长
您现在的位置: 网络学院 >> 程序设计 >> VC编程 >> 文章正文
  Archive for the Linux Category --Dbus study            【字体:
Archive for the Linux Category --Dbus study
作者:佚名    文章来源:不详    点击数:    更新时间:2007-9-12    

Archive for the Linux Category

来自: http://www.robotercoding.com/blog/?cat=3 

d-bus系统相当庞大,源代码有100多文件,大小差不多有2M,接口很复杂,即使使用glib的绑定接口,应用程序需要编写的代码都比较多,也需要了解d-bus的一些细节。
正在装载数据……
因此开发平台时,希望能够把d-bus完全封装掉,上层应用程序不用知道d-bus的概念,他们对是否采用d-bus,dcop,或者直接使用scoket都不关心。

qt4发布了一个QtDBus,用于qt的绑定,与glib的绑定基本类似,很适合qt的使用习惯。

有几个问题:
1.变参无法封装掉,c里面使用可变参数是很通常的做法,dbus提供的很多接口都是可变参数,如dbus_message_get_args,可以一次性把所有参数内容取出来,应用程序需要直接填充参数字段。但是用C++来封装似乎很麻烦,还没有找到较好的方法,但是可以不用dbus的变参接口。
2.dbus-glib做了很好的封装,对消息的发送和处理过程都封装得不错,应用可以不用知道底层的一些细节。但是dbus-glib的消息分派有自己的一套,会和将要开发的消息处理框架有冲突。相当于一套系统中有两套消息处理系统,这样会打架的,因此也不能使用dbus-glib,只能从dbus底层接口来考虑,gpe phone也是这样做的。

准备借鉴dbus-glib的封装方式,使用一个xml文件描述接口内容,再分别生成client端的发送消息接口,server端的消息接收处理接口。client的应用可以直接调用发送消息接口,server端应用可以直接处理消息结束接口,在dbus-glib中,server端是使用回调函数来处理,C++中可以使用虚函数来处理。这样的方式其实就是dbus-glib的方式,但是封装dbus底层接口的好处是可以将dbus控制到自己手中,和其他的消息处理系统一块运行。

server端的编写

在GLib中,通过dbus表现出GObject,必须写XML文件描述这个对象的方法等属性。像上一篇文章中提到的例子:

<?xml version="1.0" encoding="UTF-8" ?>
<node name="/com/example/MyObject">
<interface name="com.example.MyObject">
<method name="ManyArgs">
<arg type="u" name="x" direction="in" />
<arg type="s" name="str" direction="in" />
<arg type="d" name="trouble" direction="in" />
<arg type="d" name="d_ret" direction="out" />
<arg type="s" name="str_ret" direction="out" />
</method >
</interface >
</node >

一旦写完XML,运行dbus-binding-tool工具,如 dbus-binding-tool –mode=glib-server my-object.xml > my-object-glue.h.

然后在本地代码中include产生的头文件,调用dbus_g_object_class_install_info进行类的初始化,传递对象和对象信息进去,如 dbus_g_object_type_install_info (COM_FOO_TYPE_MY_OBJECT, &com_foo_my_object_info);每个对象类都需要这样做。

为了执行方法,需要定义一个C函数,如my_object_many_args,需要遵守的规则如下:
1.函数返回gboolean,true表示成功,false标识失败。
2.第一个参数必须是对象实例的指针。
3.跟在实例指针后面的参数是方法的输入参数。
4.输入参数后面是输出参数。
5.最后一个参数必须是GError **,如果函数返回失败,必须使用g_set_error填充该错误参数。
如下的xml文件

<method name="Increment">
<arg type="u" name="x" />
<arg type="u" direction="out" />
</method>

对应的函数定义为:
gboolean
my_object_increment (MyObject *obj, gint32 x, gint32 *ret, GError **error);

最后可以使用dbus_g_connection_register_g_object输出一个对象,如
dbus_g_connection_register_g_object (connection,”/com/foo/MyObject”, obj);

server端的声明(Annotations):
org.freedesktop.DBus.GLib.CSymbol
org.freedesktop.DBus.GLib.Async
org.freedesktop.DBus.GLib.Const
org.freedesktop.DBus.GLib.ReturnVal

client端编写

我们的程序在使用dbus的时候,首先需要连接上dbus,使用dbus_g_bus_get获得dbus连接。然后可以创建代理对象。

需要调用方法的时候,可以有两种方式:1.同步调用,使用dbus_g_proxy_call发送方法请求到远端对象,dbus会阻塞等待远端对象的回应,输出参数里将会带有相应的回应数据,以G_TYPE_INVALID作为终止符。2.异步调用,使用dbus_g_proxy_begin_call,它将返回一个DBusGPendingCall对象,可以使用dbus_g_pending_call_set_notify连接到自己的处理函授中。

可以使用dbus_g_proxy_add_signal 和 dbus_g_proxy_connect_signal来连接信号,dbus_g_proxy_add_signal用来声明信号处理函数,属于必须被调用的接口,dbus_g_proxy_connect_signal可以调用多次。

Generated Bindings
使用内置的xml文件,可以很方便地自动创建出易于使用的dbus代理对象。如下的一个xml文件描述了了一个方法:


<?xml version="1.0" encoding="UTF-8" ?>
<node name="/com/example/MyObject">
<interface name="com.example.MyObject">
<method name="ManyArgs">
<arg type="u" name="x" direction="in" />
<arg type="s" name="str" direction="in" />
<arg type="d" name="trouble" direction="in" />
<arg type="d" name="d_ret" direction="out" />
<arg type="s" name="str_ret" direction="out" />
</method >
</interface >
</node >

“in”标识输入参数,“out”标识输出参数。
使用dbus-binding-tool工具来生成头文件,如dbus-binding-tool –mode=glib-client my-object.xml > my-object-bindings.h,会产生如下的内联函数原型:

/* This is a blocking call */
gboolean
com_example_MyObject_many_args (DBusGProxy *proxy, const guint IN_x,
const char * IN_str, const gdouble IN_trouble,
gdouble* OUT_d_ret, char ** OUT_str_ret,
GError **error);

/* This is a non-blocking call */
DBusGProxyCall*
com_example_MyObject_many_args_async (DBusGProxy *proxy, const guint IN_x,
const char * IN_str, const gdouble IN_trouble,
com_example_MyObject_many_args_reply callback,
gpointer userdata);

/* This is the typedef for the non-blocking callback */
typedef void
(*com_example_MyObject_many_args_reply)
(DBusGProxy *proxy, gdouble OUT_d_ret, char * OUT_str_ret,
GError *error, gpointer userdata);

所有函数的第一个参数都是DBusGProxy对象,一般是使用dbus_g_proxy_new_*函数创建出来的。客户端发送方法请求可以增加标记,目前只有org.freedesktop.DBus.GLib.NoReply标记,dbus可以不要回应消息,没有“out”参数,这样运算速度会快一点。

Glib绑定接口在"dbus/dbus-glib.h"头文件中定义。
dbus和glib的数据类型映射如下:

D-Bus basic type GType Free function Notes
BYTE G_TYPE_UCHAR    
BOOLEAN G_TYPE_BOOLEAN    
INT16 G_TYPE_INT   Will be changed to a G_TYPE_INT16 once
GLib has it
UINT16 G_TYPE_UINT   Will be changed to a G_TYPE_UINT16 once
GLib has it
INT32 G_TYPE_INT   Will be changed to a G_TYPE_INT32 once
GLib has it
UINT32 G_TYPE_UINT   Will be changed to a G_TYPE_UINT32 once
GLib has it
INT64 G_TYPE_GINT64    
UINT64 G_TYPE_GUINT64    
DOUBLE G_TYPE_DOUBLE    
STRING G_TYPE_STRING g_free  
OBJECT_PATH DBUS_TYPE_G_PROXY g_object_unref The returned proxy does not have an interface set; use
dbus_g_proxy_set_interface to invoke methods

Container type mappings
dbus数据也有包容器类型,像DBUS_TYPE_ARRAY 和 DBUS_TYPE_STRUCT,dbus的数据类型可以是嵌套的,如有一个数组,内容是字符串的数组集合。

但是,并不是所有的类型都有普通的使用,DBUS_TYPE_STRUCT应该可以包容非基本类型的数据类型。glib绑定尝试使用比较明显的方式进行声明。

D-Bus type signature Description GType C typedef Free function Notes
as Array of strings G_TYPE_STRV char ** g_strfreev  
v Generic value container G_TYPE_VALUE GValue * g_value_unset The calling conventions for values expect that method callers have
allocated return values; see below.

同时定义了新的数组类型集合。

D-Bus type signature Description GType C typedef Free function Notes
ay Array of bytes DBUS_TYPE_G_BYTE_ARRAY GArray * g_array_free  
au Array of uint DBUS_TYPE_G_UINT_ARRAY GArray * g_array_free  
ai Array of int DBUS_TYPE_G_INT_ARRAY GArray * g_array_free  
ax Array of int64 DBUS_TYPE_G_INT64_ARRAY GArray * g_array_free  
at Array of uint64 DBUS_TYPE_G_UINT64_ARRAY GArray * g_array_free  
ad Array of double DBUS_TYPE_G_DOUBLE_ARRAY GArray * g_array_free  
ab Array of boolean DBUS_TYPE_G_BOOLEAN_ARRAY GArray * g_array_free  

定义了字典类型

D-Bus type signature Description GType C typedef Free function Notes
a{ss} Dictionary mapping strings to strings DBUS_TYPE_G_STRING_STRING_HASHTABLE GHashTable * g_hash_table_destroy  

Bus Names
当一个应用程序连接上bus daemon时,daemon会分配一个唯一的名字给它。以冒号(:)开始,这些名字在daemon的生命周期中是不会改变的,可以认为这些名字就是一个IP地址。当这个名字映射到应用程序的连接上时,应用程序可以说拥有这个名字。同时应用可以声明额外的容易理解的名字,比如可以取一个名字com.mycompany.TextEditor,可以认为这些名字就是一个域名。其他应用程序可以往这个名字发送消息,执行各种方法。

名字还有第二个重要的用途,可以用于跟踪应用程序的生命周期。当应用退出(或者崩溃)时,与bus的连接将被OS内核关掉,bus将会发送通知,告诉剩余的应用程序,该程序已经丢失了它的名字。名字还可以检测应用是否已经启动,这往往用于只能启动一个实例的应用。

Addresses
使用d-bus的应用程序既可以是server也可以是client,server监听到来的连接,client连接到server,一旦连接建立,消息就可以流转。如果使用dbus daemon,所有的应用程序都是client,daemon监听所有的连接,应用程序初始化连接到daemon。

dbus地址指明server将要监听的地方,client将要连接的地方,例如,地址:unix:path=/tmp/abcdef表明server将在/tmp/abcdef路径下监听unix域的socket,client也将连接到这个socket。一个地址也可以指明是TCP/IP的socket,或者是其他的。

当使用bus daemon时,libdbus会从环境变量中(DBUS_SESSION_BUS_ADDRESS)自动认识“会话daemon”的地址。如果是系统daemon,它会检查指定的socket路径获得地址,也可以使用环境变量(DBUS_SESSION_BUS_ADDRESS)进行设定。

当dbus中不使用daemon时,需要定义哪一个应用是server,哪一个应用是client,同时要指明server的地址,这不是很通常的做法。

Big Conceptual Picture
要在指定的对象中调用指定的方法,需要知道的参数如下:
Address -> [Bus Name] -> Path -> Interface -> Method
bus name是可选的,除非是希望把消息送到特定的应用中才需要。interface也是可选的,有一些历史原因,DCOP不需要指定接口,因为DCOP在同一个对象中禁止同名的方法。

Messages - Behind the Scenes
如果使用dbus的高层接口,就可以不用直接操作这些消息。DBUS有四种类型的消息:
1.方法调用(method call) 在对象上执行一个方法
2.方法返回(method return)返回方法执行的结果
3.错误(error)调用方法产生的异常
4.信号(signal)通知指定的信号发生了,可以想象成“事件”。

要执行 D-BUS 对象的方法,需要向对象发送一个方法调用消息。它将完成一些处理并返回一个方法返回消息或者错误消息。信号的不同之处在于它们不返回任何内容:既没有“信号返回”消息,也没有任何类型的错误消息。

每个消息都有一个消息头,包含多个字段,有一个消息体,包含多个参数。可以认为消息头是消息的路由信息,消息体作为一个载体。消息头里面的字段包含发送的bus name,目标bus name,方法或者信号名字等,同时消息头里面定义的字段类型规定了消息体里面的数据格式。例如:字符“i”代表了”32-bit integer”,“ii”就代表了消息体里面有两个”32-bit integer”。

Calling a Method - Behind the Scenes
在dbus中调用一个方法包含了两条消息,进程A向进程B发送方法调用消息,进程B向进程A发送应答消息。所有的消息都由daemon进行分派,每个调用的消息都有一个不同的序列号,返回消息包含这个序列号,以方便调用者匹配调用消息与应答消息。调用消息包含一些参数,应答消息可能包含错误标识,或者包含方法的返回数据。

方法调用的一般流程:
1.使用不同语言绑定的dbus高层接口,都提供了一些代理对象,调用其他进程里面的远端对象就像是在本地进程中的调用一样。应用调用代理上的方法,代理将构造一个方法调用消息给远端的进程。
2.在DBUS的底层接口中,应用需要自己构造方法调用消息(method call message),而不能使用代理。
3.方法调用消息里面的内容有:目的进程的bus name,方法的名字,方法的参数,目的进程的对象路径,以及可选的接口名称。
4.方法调用消息是发送到bus daemon中的。
5.bus daemon查找目标的bus name,如果找到,就把这个方法发送到该进程中,否则,daemon会产生错误消息,作为应答消息给发送进程。
6.目标进程解开消息,在dbus底层接口中,会立即调用方法,然后发送方法的应答消息给daemon。在dbus高层接口中,会先检测对象路径,接口,方法名称,然后把它转换成对应的对象(如GObject,QT中的QObject等)的方法,然后再将应答结果转换成应答消息发给daemon。
7.bus daemon接受到应答消息,将把应答消息直接发给发出调用消息的进程。
8.应答消息中可以包容很多返回值,也可以标识一个错误发生,当使用绑定时,应答消息将转换为代理对象的返回值,或者进入异常。

bus daemon不对消息重新排序,如果发送了两条消息到同一个进程,他们将按照发送顺序接受到。接受进程并需要按照顺序发出应答消息,例如在多线程中处理这些消息,应答消息的发出是没有顺序的。消息都有一个序列号可以与应答消息进行配对。

Emitting a Signal - Behind the Scenes
在dbus中一个信号包含一条信号消息,一个进程发给多个进程。也就是说,信号是单向的广播。信号可以包含一些参数,但是作为广播,它是没有返回值的。

信号触发者是不了解信号接受者的,接受者向daemon注册感兴趣的信号,注册规则是”match rules”,记录触发者名字和信号名字。daemon只向注册了这个信号的进程发送信号。

信号的一般流程如下:
1.当使用dbus底层接口时,信号需要应用自己创建和发送到daemon,使用dbus高层接口时,可以使用相关对象进行发送,如Glib里面提供的信号触发机制。
2.信号包含的内容有:信号的接口名称,信号名称,发送进程的bus name,以及其他参数。
3.任何进程都可以依据”match rules”注册相关的信号,daemon有一张注册的列表。
4.daemon检测信号,决定哪些进程对这个信号感兴趣,然后把信号发送给这些进程。
5.每个进程收到信号后,如果是使用了dbus高层接口,可以选择触发代理对象上的信号。如果是dbus底层接口,需要检查发送者名称和信号名称,然后决定怎么做。

相关链接:
D-Bus 体系 (1)

D-Bus Tutorial进行了一些翻译加上自己的一些理解。

有很多种IPC或者网络通信系统,如:CORBA, DCE, DCOM, DCOP, XML-RPC, SOAP, MBUS, Internet Communications Engine (ICE)等等,可能会有数百种,dbus的目的主要是下面两点:
1.在同一个桌面会话中,进行桌面应用程序之间的通讯
2.桌面程序与内核或者守护进程的通信。

Dbus是一套进程通信体系,它有以下几层:
1.libdbus库,提供给各个应用程序调用,使应用程序具有通信和数据交换的能力,两个应用程序可以直接进行通信,就像是一条socket通道,两个程序之间建立通道之后,就可以通讯了。
2.消息守护进程,在libdbus的基础上创建,可以管理多个应用程序之间的通信。每个应用程序都和消息守护进程建立dbus的链接,然后由消息守护进程进行消息的分派。
3.各种包装库,有libdbus-glib,libdbus-qt等等,目的是将dbus的底层api进行一下封装。

下面有一张图可以很方便说明dbus的体系结构。
dbus

dbus中的消息由一个消息头(标识是哪一种消息)和消息数据组成,比socket的流式数据更方便一些。bus daemon 就像是一个路由器,与各个应用程序进行连接,分派这些消息。bus daemon 在一台机器上有多个实例,第一个实例是全局的实例,类似于sendmail和或者apache,这个实例有很严格的安全限制,只接受一些特定的系统消息,用于系统通信。其他bus daemon是一些会话,用于用户登录之后,在当前会话(session)中进行的通讯。系统的bus daemon 和会话的bus daemon 是分开的,彼此不会互相影响,会话bus daemon 不会去调用系统的bus daemon 。

Native Objects and Object Paths
在不同的编程语言中,都定义了一些“对象”,如java中的java.lang.Object,GLIB中的GObject,QT中的QObject等等。D-BUS的底层接口,和libdbus API相关,是没有这些对象的概念的,它提供的是一种叫对象路径(object path),用于让高层接口绑定到各个对象中去,允许远端应用程序指向它们。object path就像是一个文件路径,可以叫做/org/kde/ksdivad/sheets/3/cells/4/5等。

Methods and Signals
每个对象都有一些成员,两种成员:方法(methods)和信号(signals),在对象中,方法可以被调用。信号会被广播,感兴趣的对象可以处理这个信号,同时信号中也可以带有相关的数据。每一个方法或者信号都可以用一个名字来命名,如”Frobate” 或者 “OnClicked”。

Interfaces
每个对象都有一个或者多个接口,一个接口就是多个方法和信号的集合。dbus使用简单的命名空间字符串来表示接口,如org.freedesktop.Introspectable。可以说dbus接口相当于C++中的纯虚类。

Proxies
代理对象用于模拟在另外的进程中的远端对象,代理对象像是一个正常的普通对象。d-bus的底层接口必须手动创建方法调用的消息,然后发送,同时必须手动接受和处理返回的消息。高层接口可以使用代理来替换这些,当调用代理对象的方法时,代理内部会转换成dbus的方法调用,等待消息返回,对返回结果解包,返回给相应的方法。可以看看下面的例子,使用dbus底层接口编写的代码:
Message message = new Message("/remote/object/path", "MethodName", arg1, arg2);
Connection connection = getBusConnection();
connection.send(message);
Message reply = connection.waitForReply(message);
if (reply.isError()) {

使用代理对象编写的代码:
Proxy proxy = new Proxy(getBusConnection(), "/remote/object/path");
Object returnValue = proxy.MethodName(arg1, arg2);

客户端代码减少很多。

} else {
Object returnValue = reply.getReturnValue();
}

相关链接:
D-Bus 体系 (2)

首先需要启动守护进程
dbus-daemon –system –print-pid –print-address
结果提示 Failed to start message bus: Could not get UID and GID for username “messagebus”
dbus需要有一个messagebus用户,创建该用户即可,useradd messagebus,问题解决。

执行一个dbus测试程序,提示:D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open “/usr/var/lib/dbus/machine-id”: No such file or directory
没有machine-id文件,查了一下,需要给它定义一个id,使用dbus-uuidgen >/usr/var/lib/dbus/machine-id
产生这个文件,该问题解决。

再次执行测试程序,又有问题:Couldn’t connect to session bus: Failed to execute dbus-launch to autolaunch D-Bus session,看了帮助http://dbus.freedesktop.org/doc/dbus-launch.1.html
AUTOMATIC LAUNCHING一节,需要设置DBUS_SESSION_BUS_ADDRESS环境变量的值,先执行dbus-launch,获得了DBUS_SESSION_BUS_ADDRESS值,再export一下,最后执行测试程序,OK了

在dbus帮助中有一篇关于dbus-launch的文章,可以在脚本中启动dbus-launch,同时自动设置DBUS_SESSION_BUS_ADDRESS环境变量,脚本文件rundbus如下:

if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
## if not found, launch a new one
eval `dbus-launch --sh-syntax --exit-with-session`
echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS"
fi

执行. rundbus即可。

代码里面需要使用GValue,简单定义如下:
int nID = 10;
GValue value1 = {0};
g_value_set_int(&value1,nID);

运行时提示
GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)’ failed

查了一下,GValue需要先把类型定义好,在设置的时候会先检查类型,因此g_value_set_int会出错。
glib中的代码如下

void g_value_set_int (GValue *value,
gint v_int)
{
g_return_if_fail (G_VALUE_HOLDS_INT (value));

value->data[0].v_int = v_int;
}

glib没有自动把类型转换过去,导致调用glib需要先设置类型g_value_init(&value1, G_TYPE_INT);客户端会多一行代码。

在网上找到一个详细的GtkTreeView文档,讲解了GtkTreeView涉及的方方面面,帮我解决了很多问题,非常感谢作者。

GTK+ 2.0 Tree View Tutorial

LiPS Forum刚发布了第一个版本,定义了通讯录、语音呼叫启动器、文本输入方法应用编程接口,还有定义了能够使用的GTK控件集。

LiPS全称为Linux电话终端标准(Linux Phone Standards),旨在推动基于Linux的服务和应用程序编程接口(APIs)的标准化,也就是说Lips希望定义一套API接口,大家只要遵照这些API接口就是兼容了Lips协议,可以在支持Lips协议的手机上运行。如通讯录,Lips规定了通讯录的server接口,我们编写通讯录客户端的时候,就需要遵照Lips规定的通讯录接口。

Lips定义了一套面向服务的架构,所有的应用都是server,分成了五种类型的server:
Application Management (AM) Services
User Interface (UI) Services
Enabler Services
OS Services
Platform Management Services
每个server都定义了标准的接口,Lips主要就是制定这些接口标准。

再以通讯录为例:制定了标准的访问接口,制定了各种枚举变量等等,其他应用如果需要访问通讯录,只需要遵照这些接口就可以了。

ab_err_t ab_open_session (uint32_t index, ab_sid_t *sid, uint32_t version)
Open a session to an address book. A session id is returned if the address book is successfully opened.
ab_err_t ab_create_contact (ab_sid_t sid, ab_contact_t **contact)
create a new contact
ab_err_t ab_add_contact (ab_sid_t sid, ab_contact_t *contact, ab_uid_t *uid)
add a new contact to an address book

目前有GPE phone项目在参照Lips协议进行开发。主要开发人员有北电的,还有Access的,中国人居多。架构图如下:

总体而言,Lips架构挺不错的,面向服务的体系,各个应用可以互不影响。在技术上没有什么问题,是一种好的体系。我很怀疑Lips的主旨是否能够实现,即推动API接口的标准化。各个Linux手机厂商开发多年,都有自己的一套东西,如果把自己的东西丢掉,来兼容Lips,我想难度是很大的,接口的变化造成的影响是巨大的。如果是刚进入linux手机行业的厂商,可能会比较欢迎Lips,有现成的,拿来用就可以了。

现在的linux开发框架有很多,Access,Trolltech等都有自己的框架,一个框架的好坏主要体现在是否方便应用的开发,方便手机终端厂商添加更改自己的特色。Lips并不是规划得太好,如规定了Gtk的控件集合,在我们正在规划的系统中,这些GTK控件将被完全包装掉,所以我们的新系统也不会遵照Lips的协议。Lips制定的接口,也并不能说很完善,在开发过程中,不断变化的需求导致接口很有可能会发生变化,手机厂商需要做出是否完全遵照Lips协议的选择。

在Linux手机中,期望指定一些API接口规范来达到通用目的,我觉得不可取。应用的扩展是无止境的,不断有新的应用冒出来,是不可能给每种应用添加新接口的。在手机中不如制定一些数据格式规范来得可靠一些,比如制定通讯录的存储格式,短消息的存储格式,这样并不仅仅在linux范围中获得统一,包括windows,symbian也可以参予进来,任意手机的数据可以通用。

电信运营商比较喜欢Lips协议,Lips协议目前由法国电信主导,从电信运营商的角度看,希望有一个标准,能够控制终端厂商,在整个产业链中居于主导地位。就像现在的中国电信一样,希望控制互联网,从互联网中获取增值收益。

 



本文来源:http://blog.csdn.net/yuhang111/archive/2007/08/27/1760141.aspx
站内文章搜索 高级搜索
文章录入:admin    责任编辑:admin 
  • 上一篇文章:

  • 下一篇文章:
  • 发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口
    最新热点 最新推荐 相关文章
     directx 图形接口指南(…
     win2k下的api函数的拦截
     用crypto  api  实现公钥…
     根据别人的md5源码封装的…
     vc中使用gdi+合并jpg图片
     document/view的交互 --…
     windows下的函数hook技术
     windows api函数大全一
     用vc 6.0实现串行通信的…
     vc++技术内幕(第四版)…
  • HashTable和HashMap; Vecto…

  • [ZT]关于用jar打包(分享)

  • 浅析Spring框架下PropertyPl…

  • SPRING+STRUTS+HIBERNATE登录…

  • 一个关于Comparator的使用例…

  • jsf自定义toolbar组件

  • 摘:主题:   using springmo…

  • JSP Tag Library

  • jsp重定向forward和sendRedi…

  • struts异常_does not start …

  •   网友评论:(只显示最新10条。评论内容只代表网友观点,与本站立场无关!)
    网络学院©2007 www.23book.net
    为您提供web编程,vb编程,vc编程,服务器架设管理,数据库设计等方面的知识 站长:David