中国DOS联盟

请教了几个问题就成了高级用户, 混得这个开心啊, 哈哈哈
说明很多系统, 都没有真实地反映世界, 哈哈:P

[ Last edited by jawbin on 2006-5-28 at 16:56 ]

呵呵，有时候用typedef或者宏定义的类型确实也能算做一种简单的泛型。

不过WORD应该不是这种，实际上WORD在几乎任何平台都是16bit无符号整型。真正和当前平台CPU寄存器（机器字）宽度相当的数据类型，按照 C/C++ 标准的定义应当就是 int。在32位和16位平台上，这都是成立的。

但是到了64位CPU的时代，由于32位的int在绝大多数情况下都够用了，把它扩展到64位显得比较奢侈（特别是在移植广泛使用int数组的老代码时）。于是大家都保留了int为32位的定义。

现在严格保持机器字宽的数据类型，基本只有像 ptrdiff_t 这样跟指针运算相关的类型和 atomic_int 这样跟原子量相关的类型。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
我说的那个 HANDLE 自然不是 MFC 里的，而是各种Create和Open系API返回的那种。

对, 是 int. 但是即使 int 不再"生长", 还是摆脱不了含糊不清的状况.

在 Windows 系统中, 我几乎未听说过 handle 是真正的指针(指向一个可以直接 dereference 的内存), asbai 兄 能否示例一下?

HANDLE 在历代 sdk 里都被定义成 void* 或其等价形式，它本身是抹去了具体类型的对象 this 指针。MS甚至给出了每个Windows版本的C＋＋代码行数，记得2K是1000万行。呵呵。

关于 HANDLE 的精确定义，参见sdk的winnt.h

窃以为 SDK 中的定义仅仅是个幌子, 例如 hInstance 据说是个选择符, 不同的情况下实际上是不同的, 它统一"定义"为"HANDLE", 就是“抹煞“这样的差异,为内部实现和外部接口隔离起来,为发展考虑,同时,隔离也起了安全作用. 如果真正是一个简单的可用的数据的指针, 那么很容易被第三方(开发人员)的代码危及到内核,这是不允许的.另外,例如,一个对象也许内存重整而位置变化了,它的 handle 可以不变, 将内存管理向程序员透明化,简化代码的书写.

[ Last edited by jawbin on 2006-5-30 at 08:49 ]

Originally posted by jawbin at 2006-5-28 18:14:
窃以为 SDK 中的定义仅仅是个幌子, 例如 hInstance 据说是 DGROUP 的选择符, 不同的情况下实际上是不同的, 它统一"定义"为"HANDLE", 就是“抹 ...

嗯嗯，当然是不同的，不同的HANDLE是指向不同类型对象的this指针，相同的是它们都是指针，而且都是某个对象的this指针

在 Windows 中后来的确有 c++ 代码, 例如比较复杂的 COM 等可能就是用 c++ 的, 但是我说的是 "内核(Kernel, User, Gdi)", 通常外围组件不会象内核那样寸土必争。当然了, 后来这些"内核"中的部分也许仅仅是占位符样的东西了。

若如 asbai 兄所说, 那么一个 HWND 就是指向一个窗体对象了, 通过它可以看到窗体的各个成员的. 当然这无法验证. 但是, 正如我前面所说, 如果在 c++ 上裹上 c 接口, 真是醉得不轻.

呵呵，User32和Gdi是Win32子系统中的组件，不属于 Kernel。

至于Windows 的 Kernel里面到底用了多少汇编、多少C和多少C＋＋，这个问题实在很难说，毕竟Win32的源码是不开放的。上次派到MS总部去看Win32 源码的那些教授们回来也没写出点啥子名堂.......

不过按照MS的说法Kernel也貌似是用了大量C＋＋代码。其实C＋＋的大部分特性跟等价C相比并不损失时空效率。

一个简单的例子：实现一个FILE结构，然后定义一组对 FILE* 操作的接口－fopen、fread、fclose等等，和直接实现一个File类，其数据成员与FILE结构一致，其构造析构和其它操作与fopen、fclose、fread等对应..... 两者的实现效率至少是一样高的。在大多数编译器上，用C＋＋效率要稍微高那么一点点，因为this指针保证是通过寄存器而不是栈传递。

这个针对libc的例子同样适用于OS Kernel

Originally posted by jawbin at 2006-5-28 18:25:
若如 asbai 兄所说, 那么一个 HWND 就是指向一个窗体对象了, 通过它可以看到窗体的各个成员的. 当然这无法验证. 但是, 正如我前面所说, 如果在 c++ 上裹 ...

为C＋＋实现提供C接口的项目貌似很多。。。。。主要原因：
1. C接口兼容性最好，几乎各种程序设计语言都能够跟C接口互动
2. 大型软件项目，由于其体系结构复杂，参与人员众多，协作沟通困难等原因，有时必须使用C＋＋中的很多特性划分和封装组件，否则项目实施会很困难。实际上在越大的项目中C＋＋越能体现它的价值。
3. 为C＋＋组件提供C接口唯一的代价就是在接口层多了一次函数调用的代价，这基本不会成为什么问题。但是正如前两条所述，C接口带来了广泛的语言兼容性，而C＋＋使项目变得可行并且开发、测试和成本更低。

所以，我说的“内核“是和 MS 命名的那个 kernel 模块是不同的,因为它这个 kernel 事实上并不能真正做什么,它的安全模式都需要 User 和 Gdi, 要说 command line 的安全模式,实在觉得和 Windows 距离太远, 还没看过那时候 kernel 在干什么,呵呵.所以我不说 Kernel,而是说“内核”,因为这个是真正能工作的, 而不是那个名不副实的东西.

仅仅为一个类提供基本操作(read, write 等等)和用 c 实现是没什么高下的, 但是通过 RTTI, 异常处理等等保驾护航之后, 以及后来看到的非常方便的 ToString 等等类似的“非常贴心“的小甜饼的装饰时候,就成了资源杀手,令人生畏.

不是说 c++ 提供 c 接口有多大问题, 仅仅是从“自视甚高“的 c++ 屈就出 c 接口来, 想必心中百味陈杂.

[ Last edited by jawbin on 2006-5-28 at 19:02 ]

BIOS？若是做操作系统，我现在只相信硬件IO端口


面向对象技术中最有用的是接口，而不是（类）继承。我一直想在DOS下设计一个类似COM（通用组件模型）的东东，实现能多语言协作的面向对象开发，而且最好能实现实模式与保护模式的透明（太NB了，我设计不出来）。


类 = 结构体 + 虚函数表 + 编译器障眼法（语法）


面向对象是这样发展的：结构体指针 -> 句柄 -> 对象
所以我一直跟别人说Windows系统符合面向对象思想的


程序执行效率与编译器没多大关系（注意不是Java、.Net那样的解释器）
影响速度的主要是算法与数据结构，其次是硬件平台特性
至于汇编。如果没用MMX、SSE等并行指令集的话，一般的程序员写绝对没有优化的编译器产生的机器码好


以前在混一个论坛时看到一个人，他自以为水平很高，经常说XX语言不好
所以我用他最鄙视的VB写了个图像插值缩放程序
开始时他想当然的以为用vc写的肯定比我快，但是编译后发现速度比我的慢许多
然后他反复优化算法，最终决心用汇编重写核心代码，这才与我的差不多（没使用MMX，因为那时我俩都不懂）
自此他彻底服了，承认算法优化的重要性——居然 汇编优化的程序 跟 没有指针的VB差不多
（这件事使我认识到，如果汇编没使用MMX、SSE，千万别跟别人比速度）



我认为C++最有价值的 模板+多重继承，这才是真正现代的编译器技术

[ Last edited by zyl910 on 2006-5-28 at 20:15 ]

Originally posted by jawbin at 2006-5-28 18:58:
所以，我说的“内核“是和 MS 命名的那个 kernel 模块是不同的,因为它这个 kernel 事实上并不能真正做什么,它的安全模式都需要 User 和 Gdi, 要说 command l ...

jawbin此言。。。。让人冒汗啊，kernel本来就是完成基本的核心OS操作的，比如内存管理、进程调度等等。任何一个OS都是如此，你说的“真正做什么”的东西实际是基于kernel的shell而已，linux/unix不也是这样吗？unix的kernel照兄台的标准也是“什么都不能做”的，真正跟用户交互的当然是shell拉，只不过linux的shell是bash，很多unix的shell是ksh或csh，而windows的shell是GUI的Win32子系统而已。没有硬件，何来kernel？没有kernel何来shell？

同理，安全模式一样要何用户交互，当然也要有shell拉

从Win98开始，windows的shell实际上是IE

先来回 asbai 兄, 我说的也不是 shell, 在 windows 4.x 至少可以指定 shell, 缺省的是 explorer. 而是一个 GUI os 的基本服务, 如果把 windows 等同与 non-GUI os, 那我就无话可说了.