当前位置:  编程技术>综合

[1]构建WCF单一到多服务器之路

构建WCF单一到多服务器之路 第一部wcf一个服务

一、新建一个项目，名称：WcfServerice，如图(1)

 （图1）

二、初始界面，如图（2），

将原来IService1接口类重新改成名称IServiceFirst，将Service1 改成ServiceFirst，这是第一个服务。

重新修改其内容

  // 注意: 使用“重构”菜单上的“重命名”命令，可以同时更改代码和配置文件中的接口名“IService1”。

    [ServiceContract]

    public interface IServiceFirst

    {

        // TODO: 在此添加您的服务操作

        [OperationContract]

        /* 获得表名称   */

        string GetTableName();

 

        [OperationContract]

        /* 获得表中数据   */

        DataSet GetTableData(string tablename);

    }

       

    // 使用下面示例中说明的数据约定将复合类型添加到服务操作。

    [DataContract]

    public class Product

    {

        string _TablenName ;

        /* 数据库中表的名称   */

        [DataMember]

        public string TableName

        {

            get { return _TablenName ; }

            set { _TablenName  = value; }

        }

 

        string _Connstring;

        /* 数据库连接字符串   */

        [DataMember]

        public string Connstring

        {

            get { return _Connstring ; }

            set { _Connstring  = value; }

        }

    }

如图：

三、 添加一个服务器管理项目，如图：

项目名称：WcfServiceManager

在此项目中，添加两个引用，一个是system.configuration,其作用下面程序要用到，另一个就是system.serverModal. 这个必须的，不能少。

如图：

 

并添加如下引用 ：

四、 还要添加对项目的引用,如图：

 

五、 WcfServiceManager，添加app.config文件

 

修改配置如下：

 

      <?xmlversion="1.0"encoding="utf-8" ?>

<configuration>

  <system.serviceModel>

    <services>

      <!--添加服务-->

      <servicename=" WcfServerice.ServiceFirst"behaviorConfiguration="CalculatorServiceBehavior">

        <!--name 必须与代码中的host实例初始化的服务一样 

            behaviorConfiguration 行为配置-->

        <host>

          <baseAddresses>

            <!--添加调用服务地址-->

            <addbaseAddress="http://localhost:8000/"/>

         

[2]UIPOWER《简易版DirectUI的构建》源代码编译过程中的问题

    最近著名界面库开发厂商UIPOWER的BOSS阙海忠也开通了微博，为求粉，放出了一份《简易版DirectUI的构建》的源码

     至于源代码地址大家可以加阙总sina微博然后去下载。

     http://weibo.com/uipowertech

    下载后的源码我是用VS2012打开的。

   

 升级工程到VS2012之后就可以直接编译了。编译过程很顺利。只是有个提示说注册dll失败。这个原因是因为权限不够。因为这个界面库是以com的形式调用的，所以需要先注册如下两个组件 DUIButton.dll  DirectUICom.dll 这里我用 开始-运行 的方式 regsvr32注册会提示
模块已加载，但对dllregisterServer的调用失败，错误代码为0x80040201
原因：使用管理员权限才能注册dll


解决方法是写一个批处理放在工程的output目录下
批处理的内容如下

cd /d %~dp0
regsvr32  DirectUICom.dll
regsvr32  DUIButton.dll
pause

在批处理上点击右键-以管理员运行 就会提示注册组件成功。

我们来看看工程代码

在stdafx.h

中包含了界面库的头文件

#include "DirectUIInc.h"

而这个头文件中提供了这样两个函数

IDUIRes* OpenUI();
void CloseUI();

一个是用来初始化UI的，一个是在退出时候的操作

在 TestDirectUI.h 中有这样一个指针

IDUIRes *m_pDUIRes;

在应用程序初始化的时候同样初始化该界面库

m_pDUIRes = OpenUI();

我们可以看到OpenUI函数代码如下  

IDUIRes* OpenUI()
{
	if (g_pDUIRes != NULL) return g_pDUIRes;

	::CoInitializeEx(NULL,COINIT_APARTMENTTHREADED);
	HRESULT hErr = ::CoCreateInstance(  __uuidof(DUIRes), NULL, CLSCTX_INPROC_SERVER, IID_IDispatch, (void**)&g_pDUIRes);
	if (g_pDUIRes == NULL) return NULL;

	VARIANT_BOOL bResult = VARIANT_FALSE;
	g_pDUIRes->OpenSkin(&bResult);

	return g_pDUIRes;
}

当然，在程序退出的时候也退出界面库

void CloseUI()
{
	VARIANT_BOOL bResult = VARIANT_FALSE;
	g_pDUIRes->CloseSkin(&bResult);
	g_pDUIRes->Release();
	g_pDUIRes = NULL;

	CoUninitialize(); 
}

用过GDI+绘图的就知道，需要在app类中进行初始化，在View类或者CDialog类中进行具体的绘制操作

同样，在Directui源码中也是这样操作的。

它在

TestDirectUIDlg.h定义了如下的指针

IDirectUI *m_pDirectUI;

在OnCreate()函数里调用Init()进行初始化的操作

void CTestDirectUIDlg::Init()

{
	theApp.m_pDUIRes->CreateDirectUI((OLE_HANDLE)m_hWnd,&m_pDirectUI);

	ICommandButton *pButton = NULL;
	theApp.m_pDUIRes->CreateControl(m_pDirectUI,L"{579147B8-9D94-481A-B200-C1CBD03FA01C}",(IDUIControlBase**)&pButton);

	VARIANT_BOOL bResult = VARIANT_FALSE;
	pButton->SetText(L"aaa",&bResult);
	SkinRect rect = {20,20,100,50};
	pButton->SetRect(rect);//*/

	DUIImageBase duiimgbase;
	duiimgbase.strImagePath = L"D:\\Button.bmp";

	duiimgbase.rect.left = 1;
	duiimgbase.rect.top = 1;
	duiimgbase.rect.right = 19;
	duiimgbase.rect.bottom = 22;

	duiimgbase.rcBorder.left = 4;
	duiimgbase.rcBorder.right = 4;
	duiimgbase.rcBorder.top = 4;
	duiimgbase.rcBorder.bottom = 4;
	
	duiimgbase.bStretch = VARIANT_TRUE;
	pButton->SetBackImage(&duiimgbase,DUI_BUTTON_STATUS_NORMAL,&bResult);

}

但是这样仅仅是可以将程序运行起来。界面并没有发生改变。如图

感觉很奇怪。于是到源码中去看了看。  

传递过去的绘图的句柄和窗体句柄是一个。

为什么会导致绘图失败？这个问题太郁闷了。于是一路跟进去看它的绘制过程。最后调试到绘图的函数部分。排除了DC问题，贴图区域问题之后，终于发现问题是在于

AlphaBlend函数中。

这个函数

BLENDFUNCTION bf = { AC_SRC_OVER, 0,255, AC_SRC_ALPHA };
	BOOL bRet = ::AlphaBlend(m_hDC,rcDest.left,rcDest.top,nDestWidth,nDestHeight,
		               hDC,rcSrc.left,rcSrc.top,nSrcWidth,nSrcHeight,bf);

DWORD dErr =  GetLastError();

这个函数调用结果总是返回错误 错误代码是87 也就是说参数错误。怎么会参数错误呢？百度了一下这个函数说明

SourceConstantAlpha 指定一个alpha透明度值，这个值将用于整个源位图;该SourceConstantAlpha值与源位图的每个像素的alpha值组合;如果设置为0，就会假定你的图片是透明的;如果需要使用每像素本身的alpha值，设置SourceConstantAlpha值255（不透明）;　
AlphaFormat 这个参数控制源和目标的解析方式，AlphaFormat参数有以下值：
AC_SRC_ALPHA： 这个值在源或者目标本身有Alpha通道时（也就是操作的图本身带有透明通道信息时），提醒系统API调用函数前必须预先乘以alpha值，也就是说位图上某个像素位置的red、green、blue通道值必须先与alpha相乘。例如，如果alpha透明值是x，那么red、green、blue三个通道的值必须乘以x并且

[3]Intel处理器的保护模式-分段和分页

你知道如何才能使自己快乐起来吗？最好的办法我认为是做一件自己喜欢的事！周末的第一天上午，我在为公司做事，周末的第一天下午，我收拾了家里，洗了衣服，陪女儿看了无聊的《天线宝宝》；周末的第二天，我想做点自己的事，那就是自己启动一个OS核心，到目前为止，成功了，很顺利，自己终于有了自己的OS核心。OS核心并不重要，关键是要理解Intel处理器的几个感念，本文就希望将它们阐述清楚。几个概念当然不不包括为何将代码加载到0x7c00这种问题（由于中午喝了酒-本人已经几近崩溃，语无伦次敬请见谅！！），核心在于什么是保护模式，什么是分段，什么是分页。
        计算机OS的运行，最终要落实到访问物理内存，毕竟所有的数据都是来自于物理内存，而访问物理内存就需要先知道物理内存的地址，这个地址是实实在在的地址。然而我们的程序中使用的地址却并不一定要和这个最终的物理地址相等，那么如何将程序中使用的地址对应到实实在在的物理地址，这是一门技术，不知其所以然的人只能将其当成一种魔法！
物理内存地址生成方式：虚拟地址概念：所谓虚拟地址，那是处理器为应用程序提供的一个概念，对于Intel处理器来讲，它要么是分段虚拟地址，要么是分页虚拟地址。对于什么是分段和分页，我相信能看到这篇文章的家伙一定都很并且可能比我更了解。
分段模式的物理地址形成：定位段寄存器-〉找到段选择子-〉找到段-〉定位段的base地址-〉base地址加上指令值即offset-〉得到物理地址。
分页模式的物理地址形成：定位cr3寄存器指示的内存-〉读取其值-〉虚拟地址拆分为几个段-〉查找页表-〉得到物理地址。

        我们看到，分段模式和分页模式得到物理地址的方式截然不同，它们到底有什么区别和联系呢？本质上，Intel处理器32位保护模式的宗旨在于一个概念，那就是特权环，一个程序仅仅可以在被允许的特权环内运行，而特权环的实现就是分段。

保护模式的分段机制包括两个方面：1.特权环的概念：旨在分离系统和应用程序
2.GDT/LDT：隔离各个任务
除却分段机制，32位保护模式还有一个概念，那就是分页：
分页：提供了对虚拟内存的支持，可以使进程可用的地址空间突破物理内存的限制，整个磁盘空间被认为是虚拟的内存（如果不使用file map，那么只是整个swap空间）。在不启用分页的情况下，所有的进程共享整个内存，你必须在GDT中为每一个进程预留一个位置，还要事先预知每个进程大致需要多大的内存...而是用虚拟内存，则整个4G的地址空间为一个进程独占。

Intel 32位保护模式分为两个层次，一个是分段，一个是分页分页是位于分段之上更强的针对应用程序的保护，然而并不能完全抛弃分段。
分段：针对整部机器的特权保护，分为了几个特权环
分页：针对进程的内存隔离保护，一个进程使用一个页表
二者结合使用才是真正的带有虚拟内存的32位保护模式

关于TSS：任务切换进程的概念：进程就是一个执行绪，其指令是必须保存于内存当中的，如果OS是无虚拟内存支持的，那么GDT/LDT的重要性就会很大，必须为每一个进程单独开辟一块内存，使用LDT来将此块内存与其他进程的内存隔离开来，如果使能了虚拟内存，那么就由CR3寄存器指示的页目录来完成内存隔离。在没有虚拟内存的情况下，所谓的进程就是一个任务，其切换方式就是Intel定义的任务切换，也就是一个long jmp，jmp到哪里呢？当然是jmp到目标进程的LDT所指示的内存区域了。
任务切换：Intel并没有将任务和进程等同起来。所谓的任务切换，Intel定义为就是一个long jmp，所谓的long jmp就是一个切换段寄存器的jmp，因此Intel定义的任务着重在于和GDT的关系而非和进程的关系。Intel的任务切换是一个广义的概念，涉及特权级的切换也是任务切换的一种，因为一般而言，OS核心和应用程序不在一个特权环，当然也不在一个段中，因此在切换时肯定涉及到了段寄存器的重载，当然TR寄存器指示的TSS也被看作是一般的段，CPU能区分目标段是一般的GDT/LDT段还是TSS，如果是TSS，那么就相当于切换了一个“进程”。对于进程切换，更重要的是页表的切换，也就是CR3寄存器的重载，因此对于进程切换，TSS切换的意义并不是很大，只要能保证寄存器上下文以及进程栈的正确save/restore即可，而这些东西完全可以都保存在栈上，因此只需要能保证栈的切换即可

32位OS的实现：不带有虚拟内存保护：完全的以分段为依托的实现，仅仅实现OS和应用程序的隔离，并且整个应用程序的内存空间受制于安装的物理内存大小。也只能这样，否则多出去的内存数据放在哪里呢？
带有虚拟内存保护：以分段为依托（如果愿意的话，你可以最小化使用分段），仅仅将分段用于OS核心与应用程序之间的隔离，因此只需要两个代码段和两个数据段即可，对于所有进程，共享一个段，因为进程之间可以使用分页机制来互相隔离。使用分段来把这个系统分为系统空间和用户空间，然后再用分页机制将用户空间划分为不同的进程空间...后面的我就不说了吧

其实，我们不要被书籍欺骗千万不要觉得只要实现一个32位的OS，就要想尽一切办法打开A20总线，开启分页...这也许是因为你看了于渊那个学院派学者的著作，如果你再看看轻量级编程大师的著作，比如《30天自制操作系统》，你就会发现，编写一个OS其实真的很简单，没有必要打开A20，也并不一定非要开启分页...一个纯分段的OS，仍然是一个32位保护模式的OS！