学习驱动开发,这几个论坛值得经常看看

对于从事Windows驱动开发的朋友,或者是对Windows内核感兴趣的朋友,以下几个BLOG值得经常看看!

1,Kernel Mustard by Steve Dispensa link: http://kernelmustard.com/category/ddk/

他以前的BLOG地址为:http://msmvps.com/blogs/kernelmustard/default.aspx

2,Larry Osterman's WebLog - Confessions of an Old Fogey

http://blogs.msdn.com/larryosterman/

3,Raymond Chen的The Old New Thing

http://blogs.msdn.com/oldnewthing/

4,Pointless Blathering - 作者是 User-Mode Driver Framework 的Development Lead

http://blogs.msdn.com/peterwie/

5,A Hole In My Head - Doron Holan's musings on kernel mode drivers and other nibbles and bits

http://blogs.msdn.com/doronh/

6,Windows Internals作者Mark的BLOG

http://www.sysinternals.com/Blog/

7, craigrow: blogging about developing, testing and getting a logo for your drivers using the Windows Driver Kit and the Driver Test Manager

http://blogs.msdn.com/craigrow/

8,关于代码安全的Michael Howard's Web Log - A Simple Software Security Guy at Microsoft!

Web站点:

http://www.osronline.com/,技术含量很高的Windows驱动开发站点,该站点的list基本上覆盖了所有Windows驱动开发的常见问题,强烈推荐;
http://www.microsoft.com/whdc,微软的驱动开发资源主页,可以获取很多官方资料;
http://www.wd-3.com/,该站点收集了一些比较好的Windows驱动开发方面的文章和示例代码;
http://www.sysinternals.com/,Inside Windows 2000的作者之一创建的站点,有很多内核方面的工具和示例代码;

http://www.driverdevelop.com/forum,国内最大的驱动开发技术论坛;
http://www.rootkit.com/,顾名思义,该站点上有很多Windows内核rootkit的文章和代码;
http://www.ndis.com/,NDIS驱动开发的资源站点;
http://www.pcausa.com/,NDIS的各类驱动的相关资源;
http://www.wdmaudiodev.com/,WDM 音频驱动开发的资源站点。
个人站点:

http://blogs.msdn.com/doronh/,A Hole In My Head
http://www.sysinternals.com/Blog/,大名鼎鼎的Windows Internals的作者Mark的BLOG
http://kernelmustard.com/category/ddk/,A blog by Steve Dispensa about Microsoft Windows development, focused on kernel-mode driver development, the Windows DDK, WDK, and related tools.
http://blogs.msdn.com/peterwie/,Peter Wieland's thoughts on Windows driver development

学习STL的几个好的站点:

http://www.cplusplus.com/reference/stl/vector/erase.html

  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第一部分 背景知识 第1章 应重视的价值,也是对过去几年的沉重反思 1.1 总体价值 1.2 应重视的架构风格 1.2.1 焦点之一:模型 1.2.2 焦点之二:用例 1.2.3 如果重视模型,就可以使用领域模型模式 1.2.4 慎重处理数据库 1.2.5 领域模型与关系数据库之间的阻抗失配 1.2.6 谨慎处理分布式 1.2.7 消息传递很重要 1.3 对过程的各个组成部分的评价 1.3.1 预先架构设计 1.3.2 领域驱动设计 1.3.3 测试驱动开发 1.3.4 重构 1.3.5 选择一种还是选择组合 1.4 持续集成 1.4.1 解决方案(或至少是正确方向上的一大步) 1.4.2 从我的组织汲取的教训 1.4.3 更多信息 1.5 不要忘记运行机制 1.5.1 有关何时需要运行机制的一个例子 1.5.2 运行机制的一些例子 1.5.3 它不仅仅是我们的过错 1.6 小结 第2章 模式起步 2.1 模式概述 2.1.1 为什么要学习模式 2.1.2 在模式方面要注意哪些事情 2.2 设计模式 2.3 架构模式 2.3.1 示例:层 2.3.2 另一个示例:领域模型模式 2.4 针对具体应用程序类型的设计模式 2.5 领域模式 2.6 小结 第3章 TDD与重构 3.1 TDD 3.1.1 TDD流程 3.1.2 演示 3.1.3 设计效果 3.1.4 问题 3.1.5 下一个阶段 3.2 模拟和桩 3.2.1 典型单元测试 3.2.2 声明独立性 3.2.3 处理困难因素 3.2.4 用测试桩替换协作对象 3.2.5 用模拟对象替换协作对象 3.2.6 设计含义 3.2.7 结论 3.2.8 更多信息 3.3 重构 3.4 小结 第二部分 应用DDD 第4章 新的默认架构 4.1 新的默认架构的基础知识 4.1.1 从以数据库为中心过渡到以领域模型为中心 4.1.2 进一步关注DDD 4.1.3 根据DDD进行分层 4.2 轮廓 4.2.1 领域模型示例的问题/特性 4.2.2 逐个处理特性 4.2.3 到目前为止的领域模型 4.3 初次尝试将UI与领域模型挂接 4.3.1 基本目标 4.3.2 简单UI的当前焦点 4.3.3 为客户列出订单 4.3.4 添加订单 4.3.5 刚才我们看到了什么 4.4 另一个维度 4.4.1 领域模型的位置 4.4.2 孤立或共享的实例 4.4.3 有状态或无状态领域模型实例化 4.4.4 领域模型的完整实例化或子集实例化 4.5 小结 第5章 领域驱动设计进阶 5.1 通过简单的TDD实验来精化领域模型 5.1.1 从Order和OrderFactory的创建开始 5.1.2 一些领域逻辑 5.1.3 第二个任务:OrderRepository+OrderNumber 5.1.4 重建持久化的实体:如何从外部设置值 5.1.5 获取订单列表 5.1.6 该到讨论实体的时候了 5.1.7 再次回到流程上来 5.1.8 总览图 5.1.9 建立OrderRepository的伪实现 5.1.10 简单讨论一下保存 5.1.11 每个订单的总量 5.1.12 历史客户信息 5.1.13 实例的生命周期 5.1.14 订单类型 5.1.15 订单的介绍人 5.2 连贯接口 5.3 小结 第6章 准备基础架构 6.1 将POCO作为工作方式 6.1.1 实体和值对象的PI 6.1.2 是否使用PI 6.1.3 运行时与编译时PI 6.1.4 PI实体/值对象的代价 6.1.5 将PI用于存储库 6.1.6 单组存储库的代价 6.2 对保存场景的处理 6.3 建立伪版本机制 6.3.1 伪版本机制的更多特性 6.3.2 伪版本的实现 6.3.3 影响单元测试 6.4 数据库测试 6.4.1 在每次测试之前重置数据库 6.4.2 在测试运行期间保持数据库的状态 6.4.3 测试之前重置测试所使用的数据 6.4.4 不要忘记不断演变的模式 6.4.5 分离单元测试和数据库调用测试 6.5 查询 6.5.1 单组查询对象 6.5.2 单组查询对象的代价 6.5.3 将查询定位到哪里 6.5.4 再次将聚合作为工具 6.5.5 将规格用于查询 6.5.6 其他查询选择 6.6 小结 第7章 应用规则 7.1 规则的分类 7.2 规则的原则及用法 7.2.1 双向规则检查:可选的(可能的)主动检查,必需的(和自动的)被动检查 7.2.2 所有状态(即使是错误状态)都应该是可保存的 7.2.3 规则应该高效使用 7.2.4 规则应该是可配置的,以便添加自定义规则 7.2.5 规则应与状态放在一起 7.2.6 规则应该具有很高的可测试性 7.2.7 系统应阻止我们进入错的状态 7.3 开始创建API 7.3.1 上下文,上下文,还是上下文 7.3.2 数据库约束 7.3.3 将规则绑定到与领域有关的转换,还是绑定到与基础架构有关的转换 7.3.4 精化原则:所有状态,即使是错误状态,都应该是可保存的 7.4 与持久化有关的基本的规则API的需求 7.4.1 回到已发现的API问题上 7.4.2 问题是什么 7.4.3 我们允许了不正确的转换 7.4.4 如果忘记检查怎么办 7.5 关注与领域有关的规则 7.5.1 需要合作的规则 7.5.2 使用基于集合的处理方法 7.5.3 基于服务的验证 7.5.4 在不应该转换时尝试转换 7.5.5 业务ID 7.5.6 避免问题 7.5.7 再次将聚合作为工具 7.6 扩展API 7.6.1 查询用于设置UI的规则 7.6.2 使注入规则成为可能 7.7 对实现进行精化 7.7.1 一个初步实现 7.7.2 创建规则类,离开最不成熟的阶段 7.7.3 设置规则列表 7.7.4 使用规则列表 7.7.5 处理子列表 7.7.6 一个API改进 7.7.7 自定义 7.7.8 为使用者提供元数据 7.7.9 是否适合用模式来解决此问题 7.7.10 复杂规则又是什么情况 7.8 绑定到持久化抽象 7.8.1 使验证接口成为可插入的 7.8.2 在保存方面实现被动验证的替代解决方案 7.8.3 重用映射元数据 7.9 使用泛型和匿名方法 7.10 其他人都做了什么 7.11 小结 第三部分 应用PoEAA 第8章 用于持久化的基础架构 8.1 持久化基础架构的需求 8.2 将数据存储到哪里 8.2.1 RAM 8.2.2 文件系统 8.2.3 对象数据库 8.2.4 关系数据库 8.2.5 使用一个还是多个资源管理器 8.2.6 其他因素 8.2.7 选择和前进 8.3 方法 8.3.1 自定义手工编码 8.3.2 自定义代码的代码生成 8.3.3 元数据映射(对象关系(O/R)映射工具) 8.3.4 再次选择 8.4 分类 8.4.1 领域模型风格 8.4.2 映射工具风格 8.4.3 起点 8.4.4 API焦点 8.4.5 查询风格 8.4.6 高级数据库支持 8.4.7 其他功能 8.5 另一个分类:基础架构模式 8.5.1 元数据映射:元数据的类型 8.5.2 标识字段 8.5.3 外键映射 8.5.4 嵌入值 8.5.5 继承解决方案 8.5.6 标识映射 8.5.7 操作单元 8.5.8 延迟加载/立即加载 8.5.9 并发控制 8.6 小结 第9章 应用NHibernate 9.1 为什么使用NHibernate 9.2 NHibernate简介 9.2.1 准备 9.2.2 一些映射元数据 9.2.3 一个小的API示例 9.2.4 事务 9.3 持久化基础架构的需求 9.3.1 高级持久化透明 9.3.2 持久化实体的生命周期所需的特定特性 9.3.3 谨慎处理关系数据库 9.4 分类 9.4.1 领域模型风格 9.4.2 映射工具风格 9.4.3 起点 9.4.4 API焦点 9.4.5 查询语言风格 9.4.6 高级数据库支持 9.4.7 其他功能 9.5 另一种分类:基础架构模式 9.5.1 元数据映射:元数据类型 9.5.2 标识字段 9.5.3 外键映射 9.5.4 嵌入值 9.5.5 继承解决方案 9.5.6 标识映射 9.5.7 操作单元 9.5.8 延迟加载/立即加载 9.5.9 并发性控制 9.5.10 额外功能:验证挂钩 9.6 NHibernate和DDD 9.6.1 程序集概览 9.6.2 ISession和存储库 9.6.3 ISession、存储库和事务 9.6.4 得到了什么结果 9.7 小结 第四部分 下一步骤 第10章 博采其他设计技术 10.1 上下文为王 10.1.1 层和分区 10.1.2 分区的原因 10.1.3 限界上下文 10.1.4 限界上下文与分区有何关联 10.1.5 向上扩展DDD项目 10.1.6 为什么对领域模型——SO分区 10.2 SOA简介 10.2.1 什么是SOA 10.2.2 为什么需要SOA 10.2.3 SOA有什么不同 10.2.4 什么是服务 10.2.5 服务中包括什么 10.2.6 深入分析4条原则 10.2.7 再来看一下什么是服务 10.2.8 OO在SOA中的定位 10.2.9 客户-服务器和SOA 10.2.10 单向异步消息传递 10.2.11 SOA如何提高可伸缩性 10.2.12 SOA服务的设计 10.2.13 服务之间如何交互 10.2.14 SOA和不可用的服务 10.2.15 复杂的消息传递处理 10.2.16 服务的可伸缩性 10.2.17 小结 10.3 控制反转和依赖注入 10.3.1 任何对象都不是孤岛 10.3.2 工厂、注册类和服务定位器 10.3.3 构造方法依赖注入 10.3.4 setter依赖注入 10.3.5 控制反转 10.3.6 使用了Spring.NET框架的依赖注入 10.3.7 利用PicoContainer.NET进行自动装配 10.3.8 嵌套容器 10.3.9 服务定位器与依赖注入的比较 10.3.10 小结 10.4 面向方面编程 10.4.1 热门话题有哪些 10.4.2 AOP术语定义 10.4.3 .NET中的AOP 10.4.4 小结 10.5 小结 第11章 关注UI 11.1 提前结语 11.2 模型-视图-控制器模式 11.2.1 示例:Joe的Shoe Shop程序 11.2.2 通过适配器简化视图界面 11.2.3 将控制器从视图解耦 11.2.4 将视图和控制器结合起来 11.2.5 是否值得使用MVC 11.3 测试驱动的Web窗体 11.3.1 背景 11.3.2 一个示例 11.3.3 领域模型 11.3.4 GUI的TDD 11.3.5 Web窗体实现 11.3.6 小结 11.3.7 用NMock创建模拟 11.4 映射和包装 11.4.1 映射和包装 11.4.2 用表示模型来包装领域模型 11.4.3 将表示模型映射到领域模型 11.4.4 管理关系 11.4.5 状态问题 11.4.6 最后的想法 11.5 小结 11.6 结束语 第五部分 附录 附录A 其他领域模型风格 附录B 已讨论的模式的目录
一 首先说说ARM的发展 可以用一片大好来形容,翻开各个公司的网站,招聘里面嵌入式占据了大半工程师职位。 广义的嵌入式无非几种:传统的什么51、AVR、PIC称做嵌入式微控制器;ARM是嵌入式微处理器;DSP;FPGA。 客观的讲,工作需求量上DSP的需求比ARM要多,而ARM和FPGA差不多。 DSP因为数字处理与通信领域的空前发展而火暴,小到MP3 射象头,大到我们军品里的控制器,应用面很广。 FPGA的兄弟一般做ANSIC(特殊芯片设计,好象是这么翻译的)。 而ARM单纯说来并不比一个单片机强多少,但是它的独特就在于不断下降的价格和提升的性能。这完全依靠于ARM公司的战略,厉害!!很佩服他们的战略眼光!! 值得注意的是:在找工作中,企业(著名的,小的不算)对单纯的ARM硬件开发工程师并不比单片机重视,很少有大企业的职位里写“从事过ARM开发优先”。 写的多的是什么?“嵌入式LINUX” 到这相信大家看出来了吧,需要的是硬件中的软件。 二 ARM是硬件还是软件 很难说,ARM是硬件,LINUX是软件。 ARM的硬件多半已经模块化了,像我这样把板子改成这样的就算动的多的了,这同样是ARM公司的战略,再次佩服。 实际中的LINUX的开发工作更多,更耗时。从这方面说ARM应该算是软件了。 在找工作中更是这样,举个例子,联想里和ARM最接近的是“BIOS工程师”是软件,MOTO里接近的是嵌入式LINUX工程师是软件。而其他很多公司把嵌入式产品开发归为硬件。 所以,不要讨论这个,好好玩转自己的板子才是关键。实在不爽你就把自己叫“嵌入式开发工程师” 三 要不要买开发板 买哪家 我的答案是“在你个人的学习方*”,但是如果看家是需要看这骗笔记的水平,个人推荐还是买现成的。 1 买 买板子可以把注意力集中在软件开发上,软件开发(尤其是驱动)可以不必担心自己硬件上的问题,我就是以便调试一边写驱动和程序,每次写驱动前就要先确认硬件没问题。 另外,买板子更省钱和时间,我自己做的板子,原理图PCB花了2周以上!制版又15天,回来以后焊接44B0 160个脚!那叫一个麻烦~~花了多少钱呢?2层板,制版费就300块!当然 我把接口都外引了,还做了个20X18的LCD背板,板子比较大。 总体下来 元件+LCD屏+PCB=11XX块!够2410的了。 再有就是买的资料相对来说比较全,但是不要指望有技术支持!都是骗人的,卖你之后就不会理你。 2 做 自己做可以更了解底层硬件,可以按照自己的要求加东西,比如我就加了GPS模块、 GPRS模块 、SD卡模块,扩了个IIC的35个键子的键盘、把LCD接口按照买的LCD改装了,可以用FPC线直接连接。做的很爽的。玩一把吗。 当然,你可以有策略的做,比如像我一样,把RAM和ROM,网络都保持和某现成的板子一样,这样他们的资料你就可以拿过来直接用,给自己留个退路。其他的如SD了 什么的自己做。都达到了~~就是费钱,费时间。 再有就是给做的朋友几点建议:尽量拿到现成的板子,尽量多搜集其他板子的全套资料,一定要拿到一张没问题的原理图。 网上流传的原理图多数是龚俊03年画的,再这里对龚俊表达一下我的敬意!!牛人! 但是那个图有个小BUG,我指的是03版的,后来的没这问题了。8019那地址线和地址有问题。还有人仿照他的PDF图画的SCH,更是漏洞百出!谴责!顺便谴责把龚俊板子偷卖的人。 3 买哪家 个人感觉分3类吧 1)首先是ZLG的,资料非常的全,感觉他是真正想教你怎么开发ARM,而不是像有的公司自己技术都没做好就做个板子出来卖钱。但是最大的不利就是价格太贵!而且主要是PHILIP的,货源比较麻烦~~可能有人说21XX系列的不贵啊,那是总线不外扩的,只能跑UCOS,不能跑UCLINUX。但是说是话,21XX系列才是ARM7的价格性能结合点。ARM7最适合做工业控制,ARM普及,销量都是怎么来的?都是ARM7来的,而44B0是典型的商业片子。但是,这里如果你看中的是为工作做准备,还是选能跑UCLINUX的吧。 但是仍然作为第一个推荐,因为菜鸟时期,合适的资料太重要了!!在这里被ZLG的务实*感动!你看人家那代码写的。 2)感觉立宇泰的44B0不错 硬件没别的,就是资料比较全的说,不像有些家,原理图直接拿人家的,还错的~~ 3)找个最便宜的 好象最便宜的有卖350的吧?也是没别的,就是即省了钱 还省时间搜集资料,至于资料全不全,别计较了~~硬件肯定好使就行吧。 四 要不要有51 AVR等单片机基础 有更好,但没有也无所谓。 两个月以前,我只是看别人做,耳濡目染~~,本科学过单片机,从来没做过。我们这的技术主干做AVR和51,我就跟他们调过C语言程序。你看出来了?我是个不折不扣的菜鸟吧? 但是做这个之前我特意找了ZLG
提供的源码资源涵盖了Java应用等多个领域,每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写,确保了在对应环境下能够无缝运行。同时,源码中配备了详细的注释和文档,帮助用户快速理解代码结构和实现逻辑。 适用人群: 适合毕业设计、课程设计作业。这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生,还是对其他领域编程感兴趣的学生,这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码,你可以掌握各平台开发的基础知识,提升编程能力和项目实战经验。 使用场景及目标: 在学习阶段,你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码,你将深入了解各平台开发的技术细节和最佳实践,逐步培养起自己的项目开发和问题解决能力。此外,在求职或创业过程中,具备跨平台开发能力的大学生将更具竞争力。 其他说明: 为了确保源码资源的可运行性和易用性,特别注意了以下几点:首先,每份源码都提供了详细的运行环境和依赖说明,确保用户能够轻松搭建起开发环境;其次,源码中的注释和文档都非常完善,方便用户快速上手和理解代码;最后,我会定期更新这些源码资源,以适应各平台技术的最新发展和市场需求。 所有源码均经过严格测试,可以直接运行,可以放心下载使用。有任何使用问题欢迎随时与博主沟通,第一时间进行解答!

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值