[MBROSTool6.26]UD升级到UDm：U启部署只需“一拖一格”，PE免改造即可加载隐藏外置！

ddsony

mdyblog 发表于 2014-8-21 15:36
》》另外这个PECMD.INI作了这样修改，以后重新使用软光盘的话，有影响吗，又要重新改回来吗？
1： 不 ...

这个确切值该如何不断修改？不用去调整ISO文件的大小吧？就是调整那个格式化界面自动估算的容量大小就可以了吧？因为我测试加载外置速度与ISO里的文件多少无关，与UDM分区大小有关。

ddsony

mdyblog 发表于 2014-8-21 15:36
》》另外这个PECMD.INI作了这样修改，以后重新使用软光盘的话，有影响吗，又要重新改回来吗？
1： 不 ...

》》我改下加载代码， 自动判断 何时不转为只读。
我的理解是根据这个值自动判断什么时候应该用普通隐藏，什么时候用深度隐藏吧？比如说，2g是个阈值，分区低于这个值就可以采用深度隐藏，速度正常。高于这个值就必须用普通隐藏，速度才能正常。这个跟只读不只读有关系吗？普通隐藏PE中自动加载UDM区必须是非只读的吗？

当然如果你的UDM加速算法能突破，确定有效，这个判断也就没必要了。

mdyblog

ddsony 发表于 2014-8-21 15:58
那我的UDM是不是又要重新改为深隐？普通隐藏如何改回深隐？

在【分区管理】 里面 删除  叫【MBROS】的分区----核心分区。
就是 深隐。

mdyblog

ddsony 发表于 2014-8-21 16:24
》》我改下加载代码， 自动判断 何时不转为只读。
我的理解是根据这个值自动判断什么时候应该用普通隐 ...

普通隐藏， 深度隐藏， 软管盘都是随时可以切换的，
用户自己 决定。

我这里说的是另一件事：
UDM都做好了， PE启动时， 该如何加载 这个分区较好。
FAT32 分区有个 阀值， 高于这个阀值， 就不要用PECMD只读加载了。

mdyblog

ddsony 发表于 2014-8-21 16:24
》》我改下加载代码， 自动判断 何时不转为只读。
我的理解是根据这个值自动判断什么时候应该用普通隐 ...

新版格式化 MOS 也支持 NTFS exFAT

mdyblog

ddsony 发表于 2014-8-21 12:32
》》我看看。 多大分区？

6.9g

调整 格式化参数（分配单元大小） ，是否可以提速啊？
可以 格式化的时候多建一个大分区，
自己随便怎么格式化。
这样不但测试。 在该为 只读软光盘， 重新拔插U盘。

mdyblog

ddsony 发表于 2014-8-21 12:32
》》我看看。 多大分区？

6.9g

调整 格式化参数（分配单元大小） ，是否可以提速啊？
可以 格式化的时候多建一个大分区，
自己随便怎么格式化。
这样不但测试。 在该为 只读软光盘， 重新拔插U盘。

ddsony

mdyblog 发表于 2014-8-21 17:15
调整 格式化参数（分配单元大小） ，是否可以提速啊？
可以 格式化的时候多建一个大分区，
自己随便怎 ...

刚才在实机环境测试分区的阈值。发现这个阈值好像是不固定的：
我上次记得做了一个差不多2g的ISO,分区也是2g，加载外置速度正常。
而这次实机测试，我的ISO只有1g零点，分区大小一路从2g，1.5，1.4，1.3，1.2，调整到最后1.1g加载速度仍然明显慢，不过要比6、7g分区的情况明显要短。2g调到1.1g变化都不明显。再1g以下测试就没什么意义了。

ddsony

mdyblog 发表于 2014-8-21 16:54
新版格式化 MOS 也支持 NTFS exFAT

祝贺，每天有改进！期待明天有新的速度问题的突破，那个win7 FAT移植有无实战性？

mdyblog

ddsony 发表于 2014-8-21 17:35
刚才在实机环境测试分区的阈值。发现这个阈值好像是不固定的：
我上次记得做了一个差不多2g的ISO,分区 ...

2G以下不用了， 直接用FAT16

2G  2.5G  3G  3.5G   4G     4.5G   5G  这些点。

mdyblog

ddsony 发表于 2014-8-21 17:38
祝贺，每天有改进！期待明天有新的速度问题的突破，那个win7 FAT移植有无实战性？

》》那个win7 FAT移植有无实战性
直接重启。。。。。。。。55555555555555

ddsony

mdyblog 发表于 2014-8-21 17:39
2G以下不用了， 直接用FAT16

2G  2.5G  3G  3.5G   4G     4.5G   5G  这些点。

今天1.1g就明显卡顿了，甭说2g以上了，包括进入PE后的文件夹浏览的卡顿。

ddsony

mdyblog 发表于 2014-8-21 17:40
》》那个win7 FAT移植有无实战性
直接重启。。。。。。。。55555555555555

这个FS驱动到底存放在什么位置，是MBR里还是引导程序里，它本身是一段程序，还是程序再包括文件分配表？是格式化命令放进去的吗？求科普。

mdyblog

ddsony 发表于 2014-8-21 17:41
今天1.1g就明显卡顿了，甭说2g以上了，包括进入PE后的文件夹浏览的卡顿。

》》今天1.1g就明显卡顿了，
格式化是直接选择FAT16。

mdyblog

ddsony 发表于 2014-8-21 17:43
这个FS驱动到底存放在什么位置，是MBR里还是引导程序里，它本身是一段程序，还是程序再包括文件分配表 ...

》》这个FS驱动到底存放在什么位置
windows\system32\drivers\  下
windows（系统）本身的。  

ddsony

mdyblog 发表于 2014-8-21 17:40 》》那个win7 FAT移植有无实战性 直接重启。。。。。。。。55555555555555

看来FAT对GPT或MBR深隐大分区UDm区的读写速度瓶颈是UDm碰到的最大挑战，这个障碍超越了，这个有FS的UDm甩其它U盘部署技术几条街！

mdyblog

ddsony 发表于 2014-8-21 18:53
看来FAT对GPT或MBR深隐大分区UDm区的读写速度瓶颈是UDm碰到的最大挑战，这个障碍超越了，这个有FS的UDm甩 ...

其实问题不大。 我们中国人是活的。
不死扣 西方的什么 哀地儿 （Idea）， 我们关注的只是能解决实际问题，.
解决实际（形而下）问题（03、XP 超大核心盘）的方案有好几个了：
(1) NTFS
(2) exFAT
(3) 做几个 子 ISO/IMG。
(4) 分成2个Udm
而且， 超过2G的 03/XP PE核心区的还真少见。 03/XP开始淘汰了。最低是7PE了。


-----还在研究纯粹是技术研究。

ddsony

mdyblog 发表于 2014-8-21 19:05  其实问题不大。 我们中国人是活的。  不死扣 西方的什么 哀地儿 （Idea）， 我们关注的只是能解决实际 ...

>> 超过2G的 03/XP PE核心区的还真少见。 03/XP开始淘汰了。最低是7PE了。
主要是综合盘的体积大，03/xp虽然开始淘汰，但要象Win98一样销声匿迹还需时日，毕竟还有那么多人在用。

ddsony

mdyblog 发表于 2014-8-21 19:05 其实问题不大。 我们中国人是活的。 不死扣 西方的什么 哀地儿 （Idea）， 我们关注的只是能解决实际 ...

>>解决实际（形而下）问题（03、XP 超大核心盘）的方案有好几个了。 UDM确实已经几近强大完善，针对FAT的效率问题，已有多套解决挂载外置程序速度和系统操作卡顿问题的具体方案，但这些方法看起来更确切地说是补救措施，好象不是根本上的解决办法。不知我的说法对不对。特别是对于我所使用的ezboot而言，它只支持FAT，对于这个环境还是那么格格不入，还只能可怜巴巴地以普通隐藏的方式苟延下来，而对于我本人而言，最好是把启动盘扔进这桶桶就能用，而不必再去把外置整合成ISO，或再移之于别的分区。

ddsony

mdyblog 发表于 2014-8-21 18:23  》》这个FS驱动到底存放在什么位置  windows\system32\drivers\ 下  windows（系统）本身的。

再请教：那个带开关的UDm+FIXDRV.WCS文件是啥东东，是不是类似DOS批处理，用以挂载核心区和数据区的命令脚本文件？

mdyblog

ddsony 发表于 2014-8-21 20:36
再请教：那个带开关的UDm+FIXDRV.WCS文件是啥东东，是不是类似DOS批处理，用以挂载核心区和数据区的命令 ...

是的。
挂载 UDm核心区、UDm数据区。
如果 UDm 同时在分区表， 适当的话，把分区表分区对应符卸掉，只留 只读 的UDm盘符,安全。

mdyblog

ddsony 发表于 2014-8-21 20:22
>>解决实际（形而下）问题（03、XP 超大核心盘）的方案有好几个了。 UDM确实已经几近强大完善，针对FAT的效 ...

改进了UDm 缓冲 算法，
测试 160M 缓冲， （4.5G分区） ，终于可以飞快了！！！
估计再优化下，可以不需要这么大的内存。

估计有戏。。。。。

mdyblog

ddsony 发表于 2014-8-21 20:22
>>解决实际（形而下）问题（03、XP 超大核心盘）的方案有好几个了。 UDM确实已经几近强大完善，针对FAT的效 ...

有改了下。 16M非常流畅。
基本上可说，解决了。

ddsony

mdyblog 发表于 2014-8-21 21:01
是的。
挂载 UDm核心区、UDm数据区。
如果 UDm 同时在分区表， 适当的话，把分区表分区对应符卸掉，只 ...

那普通隐藏要求分区表中必须显示对应的盘符才能访问UDM，是不是意味着PECMD加载的UDM必须是可写的，而不是只读的？

ddsony

mdyblog 发表于 2014-8-21 21:09
有改了下。 16M非常流畅。
基本上可说，解决了。

你指的是UDM加速算法这一根本性的方法？太强大了，楼主真是不怕做不到只怕想不到！实力不是盖的！回贴量无人撼动的头号置顶贴不是浪得虚名！这胜利的突破消息果然如期而至！每天让人惊喜，跟楼主对话真是太有意思了！太兴奋了，Orz！

ddsony

mdyblog 发表于 2014-8-21 21:05
改进了UDm 缓冲 算法，
测试 160M 缓冲， （4.5G分区） ，终于可以飞快了！！！
估计再优化下，可以不 ...

战战地问一下，分区没有再扩大的余地了？我的ISO至少7G啊C。

mdyblog

ddsony 发表于 2014-8-21 21:35
战战地问一下，分区没有再扩大的余地了？我的ISO至少7G啊C。

700 G  都没问题。

mdyblog

ddsony 发表于 2014-8-21 21:15
那普通隐藏要求分区表中必须显示对应的盘符才能访问UDM，是不是意味着PECMD加载的UDM必须是可写的，而不 ...

PECMD加载的UDM  默认是只读的。 需要是才是可写的。

我意思是有的UDm 被人故意加载到分表中了。 此时UDm可加载， 分区表也可加载。
那个脚本 故意 把 分区表加载的盘符卸载掉， 取而代之  UDm只读加载。

mdyblog

ddsony 发表于 2014-8-21 21:35
战战地问一下，分区没有再扩大的余地了？我的ISO至少7G啊C。

新版 传上了。
PECMD.EXE  换新的。

注意 --muhg 将软光盘 替换成UDm 只读加载。

EXEC =*%MyName% LOAD  "UDm+fixdrv.wcs"    --muhg    -mall  -mhide

这个版本， 对1G以上 FAT32， 只读加载时， 自动开启缓冲。

mdyblog

ddsony 发表于 2014-8-21 21:35
战战地问一下，分区没有再扩大的余地了？我的ISO至少7G啊C。

用 21M XPPE,  16G  软光盘， 浏览 16G  软光盘 非常流畅。如图：


图中 可见， 16G  FAT32 软光盘 是 只读加载的。