|
精华帖 (0) :: 良好帖 (0) :: 灌水帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-02-14
weiqingfei 写道 hyf 写道 ray_linn 写道 robbin 写道 为什么微软自己不提供win32api的C# wrapper呢？感觉很奇怪。像Python和Ruby都有全套完整的win32api的wrapper，用起来非常方便。
估计如二楼所言，这可是低低手做的，以M$的实力大概不屑做这个。 .NET Framework提供了部分Win32API到C#的映射，过于贴近底层的操作比如(SendMessage)没有映射，可能是为了避免引入过于庞杂的API，导致C#复杂化。但是有些操作，不使用底层操作，则效率欠佳。（比如在RichTextbox修改字体大小）。另外DllImport比使用JNI简单多了，也是M$不自己提供Wrapper的原因之一吧。 .net framework里面有的类是包装了很多win32api，不过是声明internal的。 MS不打算让.net framwork依赖于win32api。 这是不可能的事情。 为什么不可能？ 这样做有很多好处，不能预期 MS将来会否改动系统低层，framework api独立于系统api，可以提高可移植性。 提供了P/Invoke让你可以根据自己需要使用相关win32api，不过责任自负。MS没有理由干其他得益不大却会为自己设阻力的事情。 |
| 返回顶楼 | |
|
最后更新时间：2008-02-14
hyf 写道 weiqingfei 写道 hyf 写道 ray_linn 写道 robbin 写道 为什么微软自己不提供win32api的C# wrapper呢？感觉很奇怪。像Python和Ruby都有全套完整的win32api的wrapper，用起来非常方便。
估计如二楼所言，这可是低低手做的，以M$的实力大概不屑做这个。 .NET Framework提供了部分Win32API到C#的映射，过于贴近底层的操作比如(SendMessage)没有映射，可能是为了避免引入过于庞杂的API，导致C#复杂化。但是有些操作，不使用底层操作，则效率欠佳。（比如在RichTextbox修改字体大小）。另外DllImport比使用JNI简单多了，也是M$不自己提供Wrapper的原因之一吧。 .net framework里面有的类是包装了很多win32api，不过是声明internal的。 MS不打算让.net framwork依赖于win32api。 这是不可能的事情。 为什么不可能？ 这样做有很多好处，不能预期 MS将来会否改动系统低层，framework api独立于系统api，可以提高可移植性。 提供了P/Invoke让你可以根据自己需要使用相关win32api，不过责任自负。MS没有理由干其他得益不大却会为自己设阻力的事情。 任何东西都不可能独立于系统api，只不过是用什么方式来依赖而已。 |
| 返回顶楼 | |
|
最后更新时间：2008-02-14
纯从逻辑上来说，楼上在偷换概念
把win32换成了系统 |
| 返回顶楼 | |
|
最后更新时间：2008-02-14
javavsnet 写道 ray_linn 写道 seen 写道 记得dlee说过 你从来没展示过自己技术有多强
从这贴看得出来 不过尔尔 照你这思路 我不是每个礼拜都要发个帖子说 我又包装了netlink 我又包装了netfilter 我又包装了epoll 我又包装了libpcap 我甚至还包装了socket/sendmsg.... 呵呵 我们衷心希望您造福全人类，赶紧去为epoll和IOCP去Wrapper一个公共的API，就怕您没那个实力而已。 看打嘴仗还是蛮好玩的。期待更精彩的内容，二位都把自己的真家伙亮出来。 让你失望了 我没什么真本事的 就喜欢耍嘴皮子 |
| 返回顶楼 | |
|
最后更新时间：2008-02-14
看来什么东西都要提供一个可以和底层接口的手段
|
| 返回顶楼 | |
|
最后更新时间：2008-02-14
大概是没时间/精力测（leak啊什么的）吧。.NET里面有很多internal的好东西，就是不public好像主要都是没时间测，以及无法保证将这个接口不变等原因。
|
| 返回顶楼 | |
|
最后更新时间：2008-02-14
我们衷心希望您造福全人类，赶紧去为epoll和IOCP去Wrapper一个公共的API，就怕您没那个实力而已。
epoll和IOCP本来就够简单的了，再封装那不把别人当白痴了。看看什么cind,mina，纯粹把人当白痴，忽悠那些没做过项目的小学生。哦，struts也是。 |
| 返回顶楼 | |
|
最后更新时间：2008-02-14
ken1984 写道 epoll和IOCP本来就够简单的了，再封装那不把别人当白痴了。看看什么cind,mina，纯粹把人当白痴，忽悠那些没做过项目的小学生。哦，struts也是。
cind 应该是 cindy 吧？ 对于 cindy 和 mina ，我觉得主要的好处在于是把网络编程的常见的分层方式做了一个总结，这种分层方式有助于对代码做单元测试。对于一些常见的应用，这两者的封装都是足够用的了。当然会有一些特殊的需求是超出了作者当初的思考的范围的，在这种情况下，直接使用 epoll 或者 iocp 会更简单。 |
| 返回顶楼 | |
|
最后更新时间：2008-02-14
hyf 写道 weiqingfei 写道 hyf 写道 ray_linn 写道 robbin 写道 为什么微软自己不提供win32api的C# wrapper呢？感觉很奇怪。像Python和Ruby都有全套完整的win32api的wrapper，用起来非常方便。
估计如二楼所言，这可是低低手做的，以M$的实力大概不屑做这个。 .NET Framework提供了部分Win32API到C#的映射，过于贴近底层的操作比如(SendMessage)没有映射，可能是为了避免引入过于庞杂的API，导致C#复杂化。但是有些操作，不使用底层操作，则效率欠佳。（比如在RichTextbox修改字体大小）。另外DllImport比使用JNI简单多了，也是M$不自己提供Wrapper的原因之一吧。 .net framework里面有的类是包装了很多win32api，不过是声明internal的。 MS不打算让.net framwork依赖于win32api。 这是不可能的事情。 为什么不可能？ 这样做有很多好处，不能预期 MS将来会否改动系统低层，framework api独立于系统api，可以提高可移植性。 提供了P/Invoke让你可以根据自己需要使用相关win32api，不过责任自负。MS没有理由干其他得益不大却会为自己设阻力的事情。 上次听微软培训时，讲师也是这么说的，在Longhorn Server上将这么做。 微软已经放出了Windows SDK for Windows Server 2008 and .NET Framework 3.5，目前在下载中  ...看看能不能从中找到答案
|
| 返回顶楼 | |
|
最后更新时间：2008-02-15
问一下啊，那个对性能极度苛刻的地方还是需要wrapper的吧？比如directx和com+
搞游戏必须本地代码 企业开发就考虑开发效率wrapper一下也是可以的，微软 wrapper了com+继续赚钱 |
| 返回顶楼 | |
