OS updates and the hive-based registry

本文详细介绍了在更新Windows Mobile 5.0设备时,如何管理和保留持久注册表信息,包括使用单独文件存储变更、导入自定义配置到注册表等策略。

http://blogs.msdn.com/b/ce_base/archive/2005/09/22/472807.aspx


I attempted to document this behavior in the file that has become http://msdn.microsoft.com/library/en-us/wcedata5/html/wce50conUpgradingtheHiveBasedRegistry.asp.  It is not very discoverable information though, I fear.  And some of the information in that doc has gotten vague as more hands have crossed over it.  I swear there used to be more information there, but it has disappeared into the void.  Here I'll attempt to recreate it.

 

The system.hv and user.hv file on your device's persistent store are tied to default.hv and user.hv in ROM.  All of these files have an MD5 hash of your "reginit.ini" file from your release directory stored in them.  If you build a new image with a new system.hv/user.hv, then the MD5 hash in those files will be different than the hash in the ones on the persistent store.  If you download the new image onto a device with persistent registry files that went along with a previous image, the persistent files will be deleted during boot.  They MUST be deleted, really, because the persistent files contain many cross-links to the data inside the ROM files, which will be invalid if you change the ROM files.  The registry would be severely broken.  We don't delete the files just to be annoying, but because we have no choice.

 

You might find that on day-to-day rebuilds, you can keep your registry.  That happens if you haven't changed any of the .reg files that go into your image, because reginit.ini would still be the same, so even if you rebuild new default.hv/user.hv files for ROM, they have the same hash stored inside them and the persistent files can still work.  But as soon as you modify a .reg file, even just to add whitespace or comments, your persistent files will be wiped.

 

You actually have two options, if you need to update the image without losing the persistent registry.

  1. Probably your best option for your update is to keep the same system.hv/user.hv in ROM, and store any registry changes that go with the update in a separate file of your own.  Then you'd have to write a program to import those changes to the registry during the update.  You can keep the same file if you don't change .reg files at all -- but chances are, as part of your own work, you may have already changed them and have no hope to recover the original files.  What you can do instead is get the default.hv/user.hv from the original ROM, and swap them into your new image via makeimg tricks like writing your own preromimage.bat.
    • (Sigh) I just went looking for documentation explaining that batch file, and it is lacking -- suffice to say, there are a few batch files that the build system looks for during makeimg, to let you write your own scripts to affect the image at different points during the image building process.  preromimage.bat runs at about the last step of the image-building process: after the registry has been built but before everything has been built into the image.  If you write a preromimage.bat and set up your system to copy it into your release directory, then you can use preromimage.bat to do things like copy previously-saved default.hv/user.hv into your release directory, so that those go into the image instead of the ones that are built from your own .reg files.  I don't know what other .bat file call-outs there might be, but I think there might be preregcomp.bat, postregcomp.bat, prefmerge.bat, postfmerge.bat.  Look here for a little more info.
    • This option means you'd probably have to build some tool to parse your reginit.ini and pull out the things that are different from what is in the default.hv/user.hv that you'd be putting into ROM.  We don't have anything to help you do that.  :-(  Nor do we have anything to help you import those differences to the persistent registry during the update.
  2. The alternative is to enumerate the entire registry to some file of your own before the update, then do the update (which would give you a completely new registry), then import the settings from the file you exported after the update.  The tricky thing there is to know what settings NOT to write -- since your update might have changed some settings.

Neither option is great, I know.  The image update solution that is built into Windows Mobile 5.0 and that will possibly ** be available in future embedded releases deals with this problem basically by putting an empty default.hv/user.hv in ROM from the start, and importing everything during the first boot after an update.

 

** I have to say "possibly" because I can never promise what is going to be in future releases.  I cannot guarantee anything.

欧姆龙FINS(工厂集成网络系统)协议是专为该公司自动化设备间数据交互而设计的网络通信标准。该协议构建于TCP/IP基础之上,允许用户借助常规网络接口执行远程监控、程序编写及信息传输任务。本文档所附的“欧ronFins.zip”压缩包提供了基于C与C++语言开发的FINS协议实现代码库,旨在协助开发人员便捷地建立与欧姆龙可编程逻辑控制器的通信连接。 FINS协议的消息框架由指令头部、地址字段、操作代码及数据区段构成。指令头部用于声明消息类别与长度信息;地址字段明确目标设备所处的网络位置与节点标识;操作代码定义了具体的通信行为,例如数据读取、写入或控制器指令执行;数据区段则承载实际交互的信息内容。 在采用C或C++语言实施FINS协议时,需重点关注以下技术环节: 1. **网络参数设置**:建立与欧姆龙可编程逻辑控制器的通信前,必须获取控制器的网络地址、子网划分参数及路由网关地址,这些配置信息通常记载于设备技术手册或系统设置界面。 2. **通信链路建立**:通过套接字编程技术创建TCP连接至控制器。该过程涉及初始化套接字实例、绑定本地通信端口,并向控制器网络地址发起连接请求。 3. **协议报文构建**:依据操作代码与目标功能构造符合规范的FINS协议数据单元。例如执行输入寄存器读取操作时,需准确配置对应的操作代码与存储器地址参数。 4. **数据格式转换**:协议通信过程中需进行二进制数据的编码与解码处理,包括将控制器的位状态信息或数值参数转换为字节序列进行传输,并在接收端执行逆向解析。 5. **异常状况处理**:完善应对通信过程中可能出现的各类异常情况,包括连接建立失败、响应超时及错误状态码返回等问题的处理机制。 6. **数据传输管理**:运用数据发送与接收函数完成信息交换。需注意FINS协议可能涉及数据包的分割传输与重组机制,因单个协议报文可能被拆分为多个TCP数据段进行传送。 7. **响应信息解析**:接收到控制器返回的数据后,需对FINS响应报文进行结构化解析,以确认操作执行状态并提取有效返回数据。 在代码资源包中,通常包含以下组成部分:展示连接建立与数据读写操作的示范程序;实现协议报文构建、传输接收及解析功能的源代码文件;说明库函数调用方式与接口规范的指导文档;用于验证功能完整性的测试案例。开发人员可通过研究这些材料掌握如何将FINS协议集成至实际项目中,从而实现与欧姆龙可编程逻辑控制器的高效可靠通信。在工程实践中,还需综合考虑网络环境稳定性、通信速率优化及故障恢复机制等要素,以确保整个控制系统的持续可靠运行。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值