你可以设法通过这种方式：

1）创建asp.net Web服务应用程序。

2）实现一个Web服务，包含如下方法

[WebMethod]

public string GetClientUserName()

{

    return System.Web.HttpContext.Current.User.Identity.Name.ToString();

}

3）部署此Web服务。 不允许匿名用户访问。

4）在Silverlight应用程序中引用这个服务。

5）现在，你可以调用这个方法，获得当前WIndows用户名。

BMS（Be-Music Source）是一种用于音乐游戏的文件格式，由日本的Urao Yane与NBK于1998年创造。

发展

BMS最初是为一款名为BM98的音乐游戏设计，用于储存曲目信息和谱面，与相关的音视频文件联合构成可供弹奏的乐曲，创建者Urao Yane公开了该格式，使BMS成为了通行的标准。支持BMS的音乐游戏有：RDM、SSR、StepMania、O2Mania、Synth’N、Ruv-it、Lunatic-Rave等。

做为一种开放的文件格式，BMS先后分化出了两版：BM98（最初的BMS）和BME（扩展的BMS，E=Extended），BME在前者基础上增加了许多特性如长音、7KEY等，目前使用较为广泛，因此以下涉及的格式说明也以BME为准。

文件特征

BMS文件可被识别的扩展名为.bms或.bme，曾经用于区分BM98和BME，但在MG中并不作为判断的依据，也就是说，两个扩展名可随意混用。

格式说明

类似于XML，BMS文件内部由“标签行”构成，采用纯文本方式保存，音乐游戏程序负责解析该文件并读入所有关联的资源，最终“编译”形成完整的曲子。BMS语句以行首的“#”字符进行标识，其余行均视为注释。

BMS源文件按语句功能可分为三个区域：

1.信息区（HEADER），用于储存曲目的TAG
2.定义区（DEFINE FIELD），用于关联外部资源
3.谱面数据区（MAIN DATA FIELD），用于存储构建谱面的全部数据

常用语句与用法：（不区分大小写）

*—信息区（HEADER FIELD）—*

#PLAYER x
单人谱面/双人谱面
x=1：单人
x=3：双人

#GENRE xxxxxx
风格

#TITLE xxxxxx
曲名

#ARTIST xxxxxx
曲作者

#BPM x
每分钟的节拍数，默认值为130

#PLAYLEVEL x
难度级数

#RANK x
判定难度
x=0：very hard
x=1：hard
x=2：normal
x=3：easy

#TOTAL x
全部Note均以最高准确率命中后获得的生命值

#STAGEFILE <文件>
封面图片
<文件>：用作封面的图形文件名，bmp或png格式。主文件名相同即可，扩展名
一般写为“.bmp”。

#LNTYPE x
长音定义方式（详细说明在后面补充）
x=1：短音对模式
x=2：长音标模式

LR扩展标签（LR专用）

#DIFFICULTY x
同组中的难度划分
x=1：Beginner
x=2：Normal
x=3：Hyper
x=4：Another
x=5：Insane

#SUBTITLE xxxxxx
曲目的副标题

信息区代码示例：

//ALMAGEST [SP ANOTHER].bme

#PLAYER 1
#GENRE AKASHIC RECORDS
#TITLE Almagest
#ARTIST Galdeira
#BPM 178
#PLAYLEVEL 12
#RANK 3
#TOTAL 544
#DIFFICULTY 4

*—定义区（DEFINE FIELD）—*

#WAV<编号> <文件>
定义一个音频引用，即将曲目所需的音频资源文件关联至音频对象，以便导入谱面，其中
<编号>：36进制，2位数（取值范围：01 – ZZ）。
<文件>：被引用的音频文件名，wav或ogg格式。主文件名相同即可，扩展名一般写为“.wav”。

例如：
#WAV01 0001.wav  //将0001.wav或0001.ogg关联至WAV01
#WAV02 0002.wav  //将0002.wav或0002.ogg关联至WAV02
#WAV4T 004t.wav  //将004t.wav或004t.ogg关联至WAV4T

#BMP<编号> <文件>
定义一个图片引用，图片对象与图形文件关联，用于实现背景动画，其中<编号>：36进制，2位数（取值范围：01 – ZZ）。
<文件>：被引用的图形文件名，bmp或png格式。主文件名相同即可，扩展名一般写为“.bmp”。

例如：
#BMP04 01_00.bmp  //将01_00.bmp或01_00.png关联至BMP04
#BMP05 01_01.bmp  //将01_01.bmp或01_01.png关联至BMP05
#BMPZZ 01_03.bmp  //将01_03.bmp或01_03.png关联至BMPZZ

#BPM<编号> <数值>
定义BPM引用，用于阶段性变速，其中
<编号>：36进制，2位数（取值范围：01 – ZZ）。
<数值>：BPM值，可以取小数。

例如：
#BPM01 188   //BPM01=188
#BPM02 90.5  //BPM02=90.5
#BPMRR 100   //BPMRR=100

*—谱面数据区（MAIN DATA FIELD）—*

此处数据结构类似由小节和通道构成的二维数组，语句行格式如下

#<小节><通道>:<数据>

<小节>：数据所在的当前小节编号，三位十进制数（000 – 999）。
<通道>：通道编号，两位十进制数。
<数据>：由对象编号依次组成的序列，代表当前通道内相应对象在小节中的位置。

例如：

#00201:03030303 该行表示第2小节的通道1（背景通道）上共有四个编号为03的音频对象，这四个音频对象分别位于该小节的0（起始位）、1/4、2/4、3/4处。

#01311:03AE000000000000
该行表示第13小节的通道11（1P的1号位）上有两个音符对象，00为占位符。
该小节被8等分，03与AE位于0、1/8处。

通道编号列表（括号中为对象类型）：

01：背景音/BGM（WAV）
02：节拍
03：BPM
04：背景动画/BGA（BMP）
06：弹奏中Miss时出现的画面（BMP）
07：Layer（BMP）
08：BPM
09：暂停

11 – 17：1P的弹奏通道（WAV）
11：1号键
12：2号键
13：3号键
14：4号键
15：5号键
18：6号键
19：7号键
16：转盘

21 – 27：2P的弹奏通道（WAV）
21：1号键
22：2号键
23：3号键
24：4号键
25：5号键
28：6号键
29：7号键
26：转盘

51 – 57：1P的长音通道（WAV）
61 – 67：2P的长音通道（WAV）

特殊说明

背景音通道（01）

同一小节内可以有多个背景音通道并存，例如：

#00701:00BW00BY000000000000C5C60000C9CA
#00701:BVJABXJCBZC0C1C2C3C4JDJEC7C8JFJG

节拍通道（02）

节拍通道中的数据为一个十进制数值，用于表示当前小节的长度，默认值为1
（4/4拍）。

例如：
#00302:0.75
表示第3小节为3/4拍

BPM通道（03）

谱面中的速度变更，除了先定义BPM对象后发送编号外，还可以直接将BPM值（不大于255的整数）以16进制发送至BPM通道中。

例如：
#00103:000000FF  //255@3/4
#00303:1A        // 11@0/1

长音

BMS提供两种长音类型，在使用前需要先进行声明，语句为：
#LNTYPE x

其中

x=1
此方式下，长音需放在单独的通道中，由一对同样的短音组成，长度为两个音符的间距，长音通道编号=对应的弹奏通道编号+40。例如：

#LNTYPE 1
.
.
.
#00051:0001000100000000
#00053:0002000000000000
#00153:0002000000000000
表示1P中1号位和3号位的两个长音

x=2
此方式下，需要定义一个长音截止符，长音位于短音通道中，由长音截止符标记结尾。例如：

#LNTYPE 2
#LNOBJ FF
.
.
.
#00012:0000000000000001
#00212:00FF000000000000
表示1P中2号位的一个长音

使用视频文件

LR与Ruv-it支持avi或mpeg文件做为背景动画，常用方法是将视频文件关联至BMP对象，然后将其发送到起始位置的BGA通道中即可。

示例：
#BMPZZ bo17t.avi
.
.
.
#00104:ZZ

需要注意的是，由于avi可以封装多种视频编码（xvid、H264等），系统需装有相应的视频解码器才能在MG中正常显示。

参考资料：

http://www.sun-inet.or.jp/~yaneurao/bm98/bmsformat.html
http://fileformats.wikia.com/wiki/Be-Music_Script
http://ja.wikipedia.org/wiki/BMS_%E9%9F%B3%E6%A5%BD%E3%82%B2%E3%83%BC%E3%83%A0

局面判重问题

五子棋程序中，一个经常遇到的问题就是需要比较两个局面是否相同。有人说，五子棋的棋盘只有15×15，逐个格子比较就可以了，但是这不是最好的方法。我相信很快会有人想到Hash，只需要为局面计算Hash值，就能达到快速比较的目的。但是，这样做会遇到一个问题：两个Hash值相同的局面，其实并不一定相同。在五子棋程序的搜索过程中，会遍历成千上万个结点，如果Hash值冲突了怎么办？

解决方法当然不可能是在Hash值冲突的时候暴力枚举格子比较局面，而是为局面另外计算一个Hash值，我把它称为HashChk。计算HashChk的方法和计算Hash的方法不能相同。这样我们就可以在Hash值冲突的时候，比较HashChk是否相同。这个道理就好比登录网站的时候要输入密码，还要输入验证码，如果密码输对了，验证码输错了，是不能登录的。HashChk就是Hash验证码。

在实际程序中，通常可以把Hash的长度设为32位，HashChk的长度设为64位。有兴趣可以算算，这种情况下两个不同局面算出相同的Hash和HashChk的概率是多少。

Zorbrist数组

Zorbrist数组是棋类游戏常用的快速计算Hash的方法。下面我们来看看这种方法是怎样工作的。

假设五子棋的棋盘和Hash值定义为：

我们相应的定义一个Zorbrist数组

数组的第一维是玩家标识，可以定义黑棋为0，白棋为1。第二维和第三维表示棋盘。我们将ZorbistKey数组填满32位的随机数。

利用这个数组，我们可以很方便的基于一个局面计算它的后续局面的Hash值：

注意，我们定义棋盘上没有任何棋子的时候Hash值为0。

使用Zobrist数组，对于相差仅仅一步棋的两个局面，产生的Hash值也完全不同。所以这样的值用作Hash表的键值非常有效。在搜索根结点的时候把Hash值设成0，在搜索时通过调用子函数MakeMove()来更新Hash值，一直让它保持和当前局面同步。

对于刚才提到的HashChk，也是采用同样的方法计算的，不过要注意的是，用于生成HashChk的随机数组必须和生成HashKey的随机数组不同。

应用

1. 实现置换表（Transition Table），记录五子棋程序以前搜索过的局面。搜索过程中一旦在置换表中找到记录，就不用继续搜索了。
2. 记录开局库。当然，开局库并不一定用Hash的方式记录，也可以用树的方式记录。

前言

在C语言中，假设我们有这样的一个函数：

int function(int a, int b);

调用时只要用result = function(1, 2);这样的方式就可以使用这个函数。但是，当高级语言被编译成计算机可以识别的机器码时，有一个问题就凸现出来：在CPU中，计算机没有办法知道一个函数调用需要多少个、什么样的参数，也没有硬件可以保存这些参数。也就是说，计算机不知道怎么给这个函数传递参数，传递参数的工作必须由函数调用者和函数本身来协调。为此，计算机提供了一种被称为栈的数据结构来支持参数传递。

栈是一种先进后出的数据结构，栈有一个存储区、一个栈顶指针。栈顶指针指向堆栈中第一个可用的数据项（被称为栈顶）。用户可以在栈顶上方向栈中加入数据，这个操作被称为压栈(push)，压栈以后，栈顶自动变成新加入数据项的位置，栈顶指针也随之修改。用户也可以从堆栈中取走栈顶，称为弹出栈(pop)，弹出栈后，栈顶下的一个元素变成栈顶，栈顶指针随之修改。

函数调用时，调用者依次把参数压栈，然后调用函数，函数被调用以后，在堆栈中取得数据，并进行计算。函数计算结束以后，或者调用者、或者函数本身修改堆栈，使堆栈恢复原装。

在参数传递中，有两个很重要的问题必须得到明确说明：

1. 按照什么顺序把参数压入堆栈
2. 函数调用后，由谁来把堆栈恢复原状

在高级语言中，通过函数调用约定来说明这两个问题。常见的调用约定有：

• stdcall
• cdecl
• fastcall
• thiscall
• naked call

stdcall

stdcall很多时候被称为pascal调用约定，因为pascal是早期很常见的一种教学用计算机程序设计语言，其语法严谨，使用的函数调用约定就是stdcall。在Microsoft C++系列的C/C++编译器中，常常用PASCAL宏来声明这个调用约定，类似的宏还有WINAPI和CALLBACK。

声明stdcall调用约定 (以前文的那个函数为例）：

int __stdcall function(int a, int b);

stdcall的调用约定意味着：

1. 参数从右向左压入堆栈
2. 函数自身修改堆栈
3. 函数名自动加前导的下划线，后面跟一个@符号，其后紧跟着参数的总字节数，形如_function@number

以上述这个函数为例，参数b首先被压栈，然后是参数a，函数调用function(1,2)调用处翻译成汇编语言将变成：

push 2                ;第二个参数入栈

push 1                ;第一个参数入栈

call function         ;调用参数，注意此时自动把cs:eip入栈

而对于函数自身，则可以翻译为：

push ebp              ;保存ebp寄存器，该寄存器将用来保存堆栈的栈顶指针，可以在函数退出时恢复

mov ebp,esp           ;保存堆栈指针

mov eax,[ebp + 8H]    ;堆栈中ebp指向位置之前依次保存有ebp,cs:eip,a,b,ebp +8指向a

add eax,[ebp + 0CH]   ;堆栈中ebp + 12处保存了b

mov esp,ebp           ;恢复esp

pop ebp

ret 8

而在编译时，这个函数的名字被翻译成_function@8

注意不同编译器会插入自己的汇编代码以提供编译的通用性，但是大体代码如此。其中在函数开始处保留esp到ebp中，在函数结束恢复是编译器常用的方法。

从函数调用看，2和1依次被push进堆栈，而在函数中又通过相对于ebp(即刚进函数时的堆栈指针）的偏移量存取参数。函数结束后，ret 8表示清理8个字节的堆栈，函数自己恢复了堆栈。

cdecl调用约定

cdecl调用约定又称为C调用约定，是C语言缺省的调用约定。cdecl意味着：

1. 参数从右向左压入堆栈
2. 调用者负责清理堆栈
3. 按C编译方式，_cdecl调用约定仅在输出函数名前面加下划线，形如_function

它的定义语法是：

int function (int a ,int b);        //不加修饰就是C调用约定

int __cdecl function(int a,int b);  //明确指出C调用约定

cdecl调用约定的参数压栈顺序是和stdcall是一样的，所不同的是由于每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。也正由于这种变化，C调用约定允许函数的参数的个数是不固定的，这是C语言的一大特色。对于前面的function函数，使用cdecl后的汇编码变成：

;调用处

push 2

push 1

call function

add esp, 8             ;注意：这里主调函数负责恢复堆栈

;被调用函数_function处

push ebp               ;保存ebp寄存器，该寄存器将用来保存堆栈的栈顶指针，可以在函数退出时恢复

mov ebp,esp            ;保存堆栈指针

mov eax, [ebp + 8H]    ;堆栈中ebp指向位置之前依次保存有ebp,cs:eip,a,b,ebp +8指向a

add eax, [ebp + 0CH]   ;堆栈中ebp + 12处保存了b

mov esp,ebp            ;恢复esp

pop ebp

ret                    ;注意，这里没有修改堆栈

由于参数按照从右向左顺序压栈，因此最开始的参数在最接近栈顶的位置，因此当采用不定个数参数时，第一个参数在栈中的位置肯定能知道，只要不定的参数个数能够根据第一个后者后续的明确的参数确定下来，就可以使用不定参数，例如对于CRT中的sprintf函数，定义为：

int sprintf(char* buffer,const char* format,...);

由于所有的不定参数都可以通过format确定，因此使用不定个数的参数是没有问题的。

fastcall

fastcall调用约定和stdcall类似，不过调用的速度更快，因为它通过寄存器传递参数。它意味着：

1. 函数的第一个和第二个双字（DWORD）或尺寸更小的参数通过ECX和EDX传递，其他参数通过从右向左的顺序压栈传送
2. 被调用函数清理堆栈
3. 按C编译方式，fastcall调用约定在输出函数名前面加“@”符号，后面加“@”符号和参数的字节数，形如@function@number

其声明语法为：

int fastcall function(int a,int b);

thiscall

thiscall是唯一一个不能明确指明的函数修饰，因为thiscall不是关键字。它是C++类成员函数缺省的调用约定。由于成员函数调用还有一个this指针，因此必须特殊处理，thiscall意味着：

1. 参数从右向左入栈
2. 如果参数个数确定，this指针通过ECX传递给被调用者，函数自己清理堆栈
3. 如果参数个数不确定，this指针在所有参数压栈后被压入堆栈，调用者清理堆栈

为了说明这个调用约定，定义如下类和使用代码：

class A

{

public:

    int function1(int a, int b);

    int function2(int a, ...);

};



int A::function1(int a, int b)

{

    return a + b;

}



int A::function2(int a, ...)

{

    va_list ap;

    va_start(ap,a);

    int i;

    int result = 0;

    for (i = 0 ; i < a ; i ++)

    {

        result += va_arg(ap,int);

    }

    return result;

}



void caller()

{

    A a;

    a.function1(1, 2);

    a.function2(3, 1, 2, 3);

}

caller函数被翻译成汇编后就变成：

;函数function1调用

push 2

push 1

lea ecx, [ebp-8]

call function1         ;注意，这里this没有被入栈

;函数function2调用

push 3

push 2

push 1

push 3

lea eax, [ebp-8]       ;这里引入this指针

push eax

call function2

add esp, 14h

可见，对于参数个数固定情况下，它类似于stdcall，不定时则类似cdecl

naked call

这是一个很少见的调用约定，一般程序设计者建议不要使用。编译器不会给这种函数增加初始化和清理代码，更特殊的是，你不能用return返回返回值，只能用插入汇编返回结果。这种调用方式定义的函数不可以充当类的成员函数，必须独立出来编写。

这一般用于实模式驱动程序设计，假设定义一个求和的加法程序，可以定义为：

//naked 调用约定。用户自己清理堆栈。不能进行原型声明，否则错误。?add@@YAHHH@Z

__declspec(naked) int add(int a,int b)

{

    __asm push ebp //必须加上两句修改栈帧，否则引用了错误的数据

    __asm mov ebp, esp

    __asm mov eax, a

    __asm add eax, b

    __asm pop ebp

    __asm ret

}

注意，这个函数没有显式的return返回值，通过eax寄存器实现结果返回，而且连退出函数的ret指令都必须显式插入。上面代码被翻译成汇编以后变成：

push ebp

mov ebp,esp

mov eax, dword ptr [ebp+8]

add eax, dword ptr [ebp+0Ch]

pop ebp

ret

注意这个修饰是和__stdcall及cdecl结合使用的，前面是它和cdecl结合使用的代码，对于和stdcall结合的代码，则变成：

__declspec(naked) int __stdcall function(int a,int b) //?add@@YGHHH@Z

{

    __asm mov eax, a

    __asm add eax, b

    __asm ret 8 //注意后面的8

}

至于这种函数被调用，则和普通的cdecl及stdcall调用函数一致。

函数调用约定导致的常见问题

如果定义的约定和使用的约定不一致，则将导致堆栈被破坏，导致严重问题，下面是两种常见的问题：

1. 函数原型声明和函数体定义不一致
2. DLL导入函数时声明了不同的函数约定

以后者为例，假设我们在DLL中声明了一种函数为：

__declspec(dllexport) int func(int a, int b); //注意，这里没有stdcall，使用的是cdecl

使用时代码为：

typedef int (*WINAPI DLLFUNC)func(int a, int b);

hLib = LoadLibrary(...);

DLLFUNC func = (DLLFUNC)GetProcAddress(...); //这里修改了调用约定，变成了WINAPI

result = func(1,2); //导致错误

由于调用者没有理解WINAPI的含义错误的增加了这个修饰，上述代码必然导致堆栈被破坏，编译时插入的checkesp函数将告诉你，堆栈被破坏了。因此必须查明宏WINAPI到底是什么意思才行(stdcall)。

资料整理+格式调整：Felicia

参考资料：

• http://hi.baidu.com/wanggang2008/blog/
• http://hi.baidu.com/samzyn/blog/item/123646e99e5fd837b80e2dea.html
• http://blog.csdn.net/qinmi/archive/2007/08/15/1744951.aspx

因为原先用的代码高亮插件CoolCode不能高亮C#代码，最近尝试着使用另一个非常优秀的代码高亮插件CodeColorer来显示代码。CodeColorer使用牛X的GeSHi库作为后端，能支持上百种不同语言的高亮，的确十分强大。

然而美中不足的是，CodeColorer的当前版本默认不支持在可视化编辑状态下插入代码，如果在HTML编辑状态下插入代码，一旦切换到可视化状态，代码格式就全乱了。

但是通过仔细观察CodeColorer的代码可以发现，作者注释掉了一段很小的代码

136
137
138
139
// if (get_user_option('rich_editing') == 'true') {

//   add_filter('mce_external_plugins', array('CodeColorerLoader', 'AddTinyMCEPlugin'));

//   add_filter('mce_buttons', array('CodeColorerLoader', 'RegisterTinyMCEButton'));

// }

这段代码正是提供可视化插入代码的功能，我们将其恢复，就能在可视化编辑器中发现一个新增的Code按钮，点它即可插入代码。通过这种方式插入代码，就算在HTML编辑状态和可视化编辑状态之间切换，也是没有问题的！

传说中的Code按钮：