饭中淹的避难所~~~~~

赞。

感觉过于强调实体，反而让概念显得不清楚了，属于过度抽象。
从现实来讲
频道和聊天者的概念会比较清晰一点。

注入代码其实无所谓用什么写，线程有个LPVOID的参数，把需要的数据全部事先写入远程进程，然后把数据地址作为参数传给远程线程就可以了。这样无需访问全局变量。

。。。。并不是说用XML不好，或者否定UI树什么的。

我也是用的MARKUP来建立UI控件树，并绑定代码。不过，我是用了一个中间的DOM抽象数据层。
这样，不管外面有什么XML，HTML甚至INI，我只要一个数据抽象层放进UI里面就好了。





@Richard Wei

我觉得有几个问题
1- UI依赖了XML。因为你如果要改变数据源，你需要改变UI内部的东西。
我做的系统里，用了抽象的DOM数据NODE的概念。XML只是建立数据NODE的一个源而已。

2- UI的创建很多都用不到。比如prototype这种，如果你想让你的UI从数据上创建，那么你就用一个从数据创建就好了。

我的系统里，UI控件的CREATE都是只有统一的一个参数，IDataNode。这样接口非常简单。

文章好，
文字颜色不好。。。。

我用RICHEDIT的WINDOWLESS模式，在codeproject上找到的代码。
最后事情归结为实现一个RTF的生成器，下载了最新的RTF文档之后，我彻底萎了。

感觉就是MVC。

GOOD, 这个可以有控件用到别的软件里吗？

epoll看看 关系socket
fork看看 关系启动服务和多进程
信号处理看看 关系错误异常
pthread看看 多线程

很好。收藏。

monodevelop以前装过，菜单文字正常，界面和设计文字全是乱码。

很好收藏！

支持，以前从未关注过高性能磁盘IO。

磁性的柯南。。。看着他变小的长大的我们这一代。

配图。。。

我最近也在想做个类似的工具
我觉得还可以增加一个东西，就是休息事件的提前通知，然后可以设置一个便条，记录下当前正在进行的工作，以便于休息后继续工作。
我现在想的是输入一段话，再进入休息状态。

good！

@Shannon
142483

GOOD!!!!
鍵盤的，用一個按鍵的狀態表，記錄當前是按下還是抬起。

我能想到的就是细分区域的优化。

@dynas
玩家位置，在userserver上有记录。
agent上有客户端和gameserver建立的绘画映射，不需要再经过userserver中转
@King
纯转发型网管。顺带有加密和解密的工作。

@LOGOS
我是在架构上支持HTTP，后台逻辑服务可以方便的利用。
你们的运营方还真是照顾呀，哈哈。

感觉上就是一个给你做好基础引导和保护模式以及中断调用等部分，然后让你用C#写操作系统逻辑层的一个东西。

应该是《操作系统》课程教学用的吧。

不过不排除以后形成一个完善的操作系统。

你也是做游戏研发的吧，
服务器端需要和官方网站的很多WEB系统对接，
如果没有一个WEB服务的话，
很多事情都很麻烦。

而且在做页游的时候，如何将POLICY服务，和页面服务，以及游戏本身的逻辑服务整合到一起，最终的答案也是所有连接统统使用WEB服务。

我还是支持加入WEB服务的做法。
从HTTP到二进制协议并不难。
考虑到越来越多的WEB整合需求，
TELNET协议无法满足需求。

@康

你说的是每个方法最初的理论基础。但并不是最好的方法。

@杨粼波
目前的方式是用单字节来表示一个类型。
类型有 int, uint, float, string

int, uint, float 又有数组类型。

string和array是带16位的Length字段。

array除了1字节的array类型指定，还带一个1字节的元素数据类型。


对整体容量的增加，有限。

不过，现在这种方式并不是最好的方式。

我认为的最好的方式，所有类型都提取成一个数据类型对象，也就是类似GOOGLE PROTOCOL BUFFER的用额外的描述生成的一个对结构体的描述。这个方式是跟我的数据对象和映射的整体逻辑架构相关的。目标是实现服务器端，在对所有数据和逻辑的描述上形成的整体架构的统一，同时将类型和表义信息从最终数据存储中去掉。

不过这种情况下，可能会出现版本问题，由于双方描述的版本差异，导致兼容性问题。我的解决方法，是把原有的类型信息，更换为FIELDINDEX信息，也就是字段索引。在结构体描述的更改过程中，遵循字段出现增加，就增长其FIELDINDEX的原则。这样，在有限的版本空间内，FIELDINDEX会精确对应到相应的字段上。如果FIELDINDEX超出值域限制，那只有放到新的结构描述中去了。

我在网络封包这块，有着很长的一个摸索过程，大概经历过以下几个阶段：
1- 结构体直接作为封包发送
2- 结构体序列化（封包内只有数据本身，手动编写序列化和反序列化的方法）
3- 结构体序列化（封包内带有类型信息，手动编写序列化和反序列化的方法）
4- 数据对象和数据映射（封包内带有字段信息，通过数据映射来序列化和反序列化）

这样做有个好处是不需要定型的struct，处理过程只要传入一个复合类型value的数组即可，对于统一整体架构，减少代码工作量很有帮助。

我使用的是类型加数值的序列化和反序列化，封包不仅用于网络，还用于db，内部消息等地方。

@康
我这里也是这种方法，不过，这里是在解决另外的问题：

当一个角色有多个可见区域的时候，
可见区域重叠，带来的广播消息的重复。

@战魂小筑
我觉得异常在新一代的语言里是用来进行错误处理的。
所以异常在我这个体系里是作为一种像是错误编号一样的数据对象存在，
能够被捕捉到，并由映射进行处理。

@Kevin Lynx
数据也脚本化，我感觉不合适。

我是要提供可视化编辑工具给策划，让他们自己去设计数据对象。

脚本这些粗活，就是服务器程序来做。

所有工具都做成各种PAD可部署的，这样就不用限制办公地点和时间了。

随时随地做事。

有个好的点子可以立即应用到实际的游戏服务中去。

@Kevin Lynx
配置+脚本共同的
每个都可以实时修改
这样该错误，更新什么的，根本不用重启了

服务器本身的程序就是一堆底层的库在那里

然后就是支持这些数据对象和映射。

数据对象虽然看起来很复杂，实际上是个简单功能的容器类，和封包的结构很像。

大部分的事情都是在映射里做的。而这些映射都是脚本的。


脚本我准备用quartz composer那种卡片式的，这样可以用IPAD，GPAD，乐PAD等各种PAD，用3G卡在某个公园的角落里摸几下就把服务器BUG给修改好了。

接着我在那边跟你说的，我是不允许代码和脚本碰数据对象的属性的。

属性必须由对象设计器生成。这个对象设计器是在线的，也就是运行时创建，更改的。

映射也是，映射说起来就是一种脚本，用来关联对象之间的属性的东西。

你那个独立博客在CHROME上会标红标骷髅头。

多重继承真的是个很大的坑。
要小心翼翼的通过。
我以前也是和你一样的用VOID*的时候出了这个问题。

@卧槽
是的，我确实是个菜鸟。

@megax
Vb的数据库部分没用过，不清楚
不过c++里面数据库的orm不是很好实现，也没有很多好的库。
另外是效率和异步考虑，数据库操作必须可控
还有必要的灵活性
所以使用了存储过程和连接线程池

不过，我找到一个新的方法来降低逻辑层的数据库相关复杂度。也是类似对象关系映射，我的方法是根据对象生成一个字段模型（字段偏移和类型表），这个作为映射中心，网络封包、数据库表作为映射源和目标。字段模型可外部编辑并从模型生成实体。

然后底层还是这种连接池。

我没看过《beautiful code》，我不全相信书
我只说自己的想法，我不引经据典
我的回复就是表达我的态度，
我不逃避
我为我每条回复负责
我不想打嘴仗
我认为自己很浅薄
我就是饭中淹。

我也想说句“卧槽”。

耗时很少，这个描述不是很精确。

首先确定你的负载到底是什么，CPU，内存，还是网络IO。
然后量化并监控你的负载情况，并集中进行管理。
最后，根据你集中管理的量化的负载情况，分配新到来的用户的接入点。

这个GUI框架挺好的
我是保留WPARAM和LPARAM
不过一些常用的消息，做进了内部逻辑了。比如onpaint这种，在这个内部逻辑里，PARAM就被转换成真实的变量了，比如HDC这样的。

另外，我直接用VS的DIALOG编辑器，编辑成无窗口模式，然后用一个FORM套住这个无窗口模式的DIALOG，就间接实现了界面的所见即所得编辑。

用法，无所谓。可用就行。

不错，深有同感。
不过自己做库，也有个很严重的问题，要想突破自己，也是比较困难的。
我自己维护了一个类似STL的库，一个网络库，还有很多杂七杂八的东西。很多次重构之后，很多架构依然还存在着，只是不断的修修补补。有时候想推翻重来，却总是因为各种原因而放弃或者失败了。
可能做项目的时候，不适合去做库的推翻重来。
不过有时候做项目时，偶尔会来一些灵感，突然获得一个能够推翻之前库里的东西的想法，但是却迟迟无法更新到库里面。因为心里在害怕，没有大量测试的代码，会导致库的不稳定。

为什么不把pointer和counter放在一个结构里，new这个结构？
我做这个东西的时候，就是做这样一个core_struct，然后加一个core_struct池来维护内存。所有的Ptr传递和保存的就是这个core_struct的指针。

顶
另外,文件分配表的位置最好放在包末尾，这样就没有数量限制了，也不用预留empty_tags。

微软的操作系统有开源。可以去找来看。

@Θ§奏之章℡
参阅和真正需求到的，完全不一样。