如何使程序编译后的Hash码都一样??

budded 2008-06-13 11:27:29
加精
程序代码没有修改过,但每次编译出来的程序Hash码都不一样,
估计是文件修改时间等信息被写入程序,Delphi有没有选项能让这个时间不编译进程序呢?

同一个程序两次编译后用FC比较的结果:
正在比较文件 About.dll 和 A.DLL
00000108: 74 54
00000109: E8 E3
0000A204: 13 57
0000A205: 5B 58
0000A224: 13 57
0000A225: 5B 58
0000A264: 13 57
0000A265: 5B 58
0000A27C: 13 57
0000A27D: 5B 58
0000A294: 13 57
0000A295: 5B 58
0000A2AC: 13 57
0000A2AD: 5B 58
0000A2C4: 13 57
0000A2C5: 5B 58
0000A2DC: 13 57
0000A2DD: 5B 58
0000A2F4: 13 57
0000A2F5: 5B 58
0000A30C: 13 57
0000A30D: 5B 58
...全文
1350 63 打赏 收藏 转发到动态 举报
写回复
用AI写文章
63 条回复
切换为时间正序
请发表友善的回复…
发表回复
僵哥 2008-06-22
  • 打赏
  • 举报
回复
[Quote=引用 64 楼 cacar2008 的回复:]
最后修改时间同步掉试/
[/Quote]
最后修改时间是不由文件带走的,也就是说文件时间(File Time)不属于文件的内容(这个我当初确实没有弄明白^_^),而是由文件系统来保存的。
cacar2008 2008-06-22
  • 打赏
  • 举报
回复
最后修改时间同步掉试/
僵哥 2008-06-20
  • 打赏
  • 举报
回复
[Quote=引用 57 楼 NBOne 的回复:]
Hash码管理这种方法就类拟于用指纹因素来管理,看拟牢靠,实际只是空中楼阁,不稳定因素太多,强列不推荐。高技术含量不代表就是最好
[/Quote]
这里无所谓牢靠不牢靠一说,为的不是防止篡改之类的,只是内部自己进行一个文件差异比较。

管理分为主动管理和被动管理两种,当制度存在一定的局限的时候,主动管理存在一定缺失,那么被动管理就成为一种必要,否则就缺失管理。

当然都期望每一个单位都有一个好的制度,但是即便是有制度也有松紧之分。在技术可以提升管理效率的情况下,个人不反对形成一种技术衍生品来对管理形成一种稽核机制。

技术永远只是作为一种手段存在,而不是制度,也更不可能替代制度。
ly_liuyang 2008-06-20
  • 打赏
  • 举报
回复
这个想法一点儿都不好~
没有任何一个成熟产品用这个方法的

人为的版本管理才是最实际的
NBOne 2008-06-20
  • 打赏
  • 举报
回复
Hash码管理这种方法就类拟于用指纹因素来管理,看拟牢靠,实际只是空中楼阁,不稳定因素太多,强列不推荐。高技术含量不代表就是最好
fuqd273 2008-06-20
  • 打赏
  • 举报
回复
人是活的,所以人会出错。

如果能将这个做成版本控制工具的辅助插件,那就完全不是一个量级上的了,才能减少混乱的可能。
僵哥 2008-06-20
  • 打赏
  • 举报
回复
[Quote=引用 60 楼 gxj760998 的回复:]
第一次听说有这样做程序版本管理的!
难不成你想做个SVN服务器??
[/Quote]
为什么允许使用SVN/CVS等版本控制就不允许用自己的程序辅助控制?人是活的。
gxj760998 2008-06-20
  • 打赏
  • 举报
回复
这个帖子是精华???
我实在看不出精华在哪里。。。。
gxj760998 2008-06-20
  • 打赏
  • 举报
回复
第一次听说有这样做程序版本管理的!
难不成你想做个SVN服务器??
僵哥 2008-06-19
  • 打赏
  • 举报
回复
[Quote=引用 47 楼 YFLK 的回复:]
有点复杂了,可把问题简化一下,只取数据的某一部分,去掉文件头和文件尾,这样可保证不同时间编译的程序不受时间的影响
[/Quote]
那只是你自己计算的时候可以控制,如果是别的程序呢?
YFLK 2008-06-19
  • 打赏
  • 举报
回复
有点复杂了,可把问题简化一下,只取数据的某一部分,去掉文件头和文件尾,这样可保证不同时间编译的程序不受时间的影响
僵哥 2008-06-19
  • 打赏
  • 举报
回复
[Quote=引用 45 楼 fuqd273 的回复:]
使用hash管理每个文件可能是好办法。。。

不过更感觉是懒人懒办法。

想要被省掉的事情是省不掉的。
版本管理里面如果不记录版本差异还叫什么版本管理?
[/Quote]
因为没有差异,所以省去不必要的差异管理。
fuqd273 2008-06-19
  • 打赏
  • 举报
回复
使用hash管理每个文件可能是好办法。。。

不过更感觉是懒人懒办法。

想要被省掉的事情是省不掉的。
版本管理里面如果不记录版本差异还叫什么版本管理?
liliangdc 2008-06-19
  • 打赏
  • 举报
回复
>干吗这样来做升级差分
liliangdc 2008-06-19
  • 打赏
  • 举报
回复
<plaintext>
liliangdc 2008-06-19
  • 打赏
  • 举报
回复
<img src="http://cimg2.163.com/dl/bbs/ding_all.gif" border="0"/>
fuqd273 2008-06-19
  • 打赏
  • 举报
回复
52楼说的没错。本来就没有说要把两者混同。两者不等价,也不具可比性。

我49楼想表达的意思是,楼主想用可执行程序的hash码来进行升级差分,
在技术上可行。从变更控制流程的角度考虑,容易导致混乱。

是50楼引入了代码优化与接口优化的区别问题,但是事实上、仅仅代码优化的话,需要进行更新的目标程序是非常明确的;只有进行接口更新了,才会导致引用共通库的应用程序进行更新、并进而导致楼主的疑问。

僵哥 2008-06-19
  • 打赏
  • 举报
回复
[Quote=引用 51 楼 fuqd273 的回复:]
模块接口定义都不做还叫什么设计文档?

某一行代码优化不代表接口优化变更。

仅仅是内部变更,接口不变更的话,引用该库的应用程序是不需要重新编译的。
简单地说,函数接口不变,引用对应lib的那些程序都是不需要重新编译的。
在变更控制流程上来说,当然可以将设计文档的变更范围控制在共通库这一点上,甚至都不需要进行设计文档的变更。

你说的那些不是代码逆向驱动设计文档的理由。
[/Quote]
关于接口设计当中引发的变更,这个跟因为没有任何代码上异动重新编译导致Hash码不一致的问题是两回事。
fuqd273 2008-06-19
  • 打赏
  • 举报
回复
模块接口定义都不做还叫什么设计文档?

某一行代码优化不代表接口优化变更。

仅仅是内部变更,接口不变更的话,引用该库的应用程序是不需要重新编译的。
简单地说,函数接口不变,引用对应lib的那些程序都是不需要重新编译的。
在变更控制流程上来说,当然可以将设计文档的变更范围控制在共通库这一点上,甚至都不需要进行设计文档的变更。

你说的那些不是代码逆向驱动设计文档的理由。
僵哥 2008-06-19
  • 打赏
  • 举报
回复
[Quote=引用 49 楼 fuqd273 的回复:]
没错,“一个公用库当中某一个函数的修改,也并不一定会对所有引用到该库的程序有所影响。”
但是作为需求变更控制流程来说,由于公用库的某一个函数的修改而进行的升级,应该将由于引用了该库该函数而真正被涉及到需要进行升级的程序标注出来,而将那些虽然引用了该库、但是没有引用变更函数而不需要更新的程序剔除出去。

从操作上来说,需求管理做得好的话,完全可以通过针对上层设计文档的改版来达到相同的目的。
而不是相反,用技术手段来逆向推动设计文档的更新。 [/Quote]
难道设计文档,会跟进每一行代码?比如说,我在不影响程序功能的情况下,进行了某一行代码的优化,这也要以设计文档当中跟进?这还是设计文档吗?但是不能说这个优化所带动的程序升级是非必要的吧?
加载更多回复(43)

16,748

社区成员

发帖
与我相关
我的任务
社区描述
Delphi 语言基础/算法/系统设计
社区管理员
  • 语言基础/算法/系统设计社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧