[更新376#2825]PECMD2012.1.80.13_Win32_64.多窗口多线程.裸机系统2.3.3.1+18M酷M...

mdyblog

红毛樱木 发表于 2017-6-4 20:46
※此命令还有一个功能：从本地磁盘中搜索驱动，如"DEVI \Windows,Display"。但此命令未完善，会提 ┃
...

1： 会完善的。

2：“DEVI \Windows,Display” 是从本机寻找驱动， 没什么用。这句式仿4.0些写的。

3：现有 再目录按类型搜索
DEVI [*rescan] [*norescan] <*sub|*self> <含有INF文件的目录>[,DevClass]      
已经实现完毕。

mdyblog

红毛樱木 发表于 2017-6-4 20:46
※此命令还有一个功能：从本地磁盘中搜索驱动，如"DEVI \Windows,Display"。但此命令未完善，会提 ┃
...

你传个03PE， PECMD.INI简单点， 2012灰卡---4.0可正常运行。我对比下。

红毛樱木

mdyblog 发表于 2017-6-5 06:30
1： 会完善的。

2：“DEVI \Windows,Display” 是从本机寻找驱动， 没什么用。这句式仿4.0些写的。

子目录不行，这个新版搞定了？

如果时间充裕的话，可以考虑研究下微软的devcon，毕竟这个是微软自己的，而且在ddk和后面的wdk中都有源代码

红毛樱木

mdyblog 发表于 2017-6-5 06:30
1： 会完善的。

2：“DEVI \Windows,Display” 是从本机寻找驱动， 没什么用。这句式仿4.0些写的。

子目录不行，这个新版搞定了？

红毛樱木

mdyblog 发表于 2017-6-5 06:32
你传个03PE， PECMD.INI简单点， 2012灰卡---4.0可正常运行。我对比下。

明天给你弄个环境。

pseudo

mdyblog 发表于 2017-6-3 17:26
是不是新版改了UD格式。
看了下，支持大于4G的IMG了。 不知道是否用的前面哪个大大的方案。
不是的话， ...

M大终于回来了。

是这样的：fbinsttool出了新版1.7，支持大于4GB的ud。
好像是基于yaya大的支持4G以上的fbinst，这里有个好像是它的plus：http://wuyou.net/forum.php?mod=v ... &extra=page%3D1

然后无法用pecmd将ud里的iso挂载到盘符Z:，而fbinsttool旧版1.6没问题。

我们这样验证：ud大于4GB，里面有iso，进64位win10pe桌面后，在命令行窗口手动执行：
pecmd moun-udm -udfs -udm- -udimg:0PE.ISO \\.\PhysicalDrive0 Z:
pecmd moun-udm -udfs -udm- -udimg:0PE.ISO \\.\PhysicalDrive1 Z:
pecmd moun-udm -udfs -udm- -udimg:0PE.ISO \\.\PhysicalDrive2 Z:
如果出现Z:盘盘符，就成功。

也许pecmd要更新一下才支持这个变动。
另外，pecmd或imdisk如果有别的命令能直接挂载也行。

mdyblog

红毛樱木 发表于 2017-6-5 12:54
子目录不行，这个新版搞定了？

如果时间充裕的话，可以考虑研究下微软的devcon，毕竟这个是微软自己 ...

功能上是支持目录的。我当时也测试过了。
既然你说“子目录不行”，那有空再测试下。

mdyblog

红毛樱木 发表于 2017-6-5 12:54
子目录不行，这个新版搞定了？

如果时间充裕的话，可以考虑研究下微软的devcon，毕竟这个是微软自己 ...

正版本支持devcon
*drvload/*devcon优先用drvload(默认)/devcon。

你把 drvload 删掉， 就用 drvcon， 默认drvload优先。

你可以用 DEVI  *drvcon   这样devcon优先。

mdyblog

红毛樱木 发表于 2017-6-5 12:54
子目录不行，这个新版搞定了？

如果时间充裕的话，可以考虑研究下微软的devcon，毕竟这个是微软自己 ...

另外：DEVI是有返回值的 %&ERROR%（建议）  或 %ERROR%
不是都有明确意义。 如果指定 *drvcon, 则有意义， 就是drvcon的错误码。

红毛樱木

mdyblog 发表于 2017-6-5 18:26
正版本支持devcon
*drvload/*devcon优先用drvload(默认)/devcon。

我说的和你说的不是一个意思.
我意思是把devcon部分代码移植，就像upnp那种的移植

红毛樱木

mdyblog 发表于 2017-6-5 19:10
另外：DEVI是有返回值的 %&ERROR%（建议）  或 %ERROR%
不是都有明确意义。 如果指定 *drvcon, 则有意 ...

这里用返回值，实际没有意义。因为如果PECMD本身调用devcon安装失败的话，PECMD会自动用自己的算法再去安装一次驱动。

mdyblog

红毛樱木 发表于 2017-6-5 19:55
我说的和你说的不是一个意思.
我意思是把devcon部分代码移植，就像upnp那种的移植

那和直接PECMD调用devcon不一样的效果吗？  

mdyblog

红毛樱木 发表于 2017-6-5 19:56
这里用返回值，实际没有意义。因为如果PECMD本身调用devcon安装失败的话，PECMD会自动用自己的算法再去安 ...

你要什么样的效果？
是要DRVCON的返回码 还是说 只调用DRVCON？

红毛樱木

mdyblog 发表于 2017-6-5 20:54
你要什么样的效果？
是要DRVCON的返回码 还是说 只调用DRVCON？

这里不用特殊处理。前面我贴了一下devcon自身的4个返回码的含义，您做下内部判断处理就可以了，还是和以前一样，不用单独做devcon的返回。

红毛樱木

mdyblog 发表于 2017-6-5 20:47
那和直接PECMD调用devcon不一样的效果吗？

现在的pecmd匹配驱动，默认截取设备唯一ID的前两段，这种做法不科学。
实际使用中需要更复杂的算法。
比如设备管理器中显示的ID信息有“硬件ID”和“兼容个ID”，这两个信息本身就有多行，而去匹配inf中的ID应该去拿这些整行整行的信息去匹配，而不是"■匹配级别：设备ID的以&分隔的节数，默认2。"

打个比方(下面的设备是虚构出来的，实际使用也是存在这种情况的):
设备唯一ID:
HDAUDIO\FUNC_01&VEN_111D&DEV_76E0&SUBSYS_103C2109&REV_1003\0000
该设备的硬件ID:
HDAUDIO\FUNC_01&VEN_111D&DEV_76E0&SUBSYS_103C2109&REV_1003
HDAUDIO\FUNC_01&VEN_111D&DEV_76E0&SUBSYS_103C2109
该设备的兼容ID:
HDAUDIO\FUNC_01&CTLR_VEN_8086&CTLR_DEV_8C20&VEN_111D&DEV_76E0&REV_1003
HDAUDIO\FUNC_01&VEN_111D&DEV_76E0
SID\ABCD
HDAUDIO\FUNC_01

INF中的信息：
%HdAudioFunctionDriver.Generic.DeviceDesc%  = HdAudModel, ,SID\ABCD


这时候用PECMD内部的匹配算法就匹配不到这个驱动了，所以我就想到把devcon移植过来，比如devcon内部有一些命令Hwids、status、.....这些还是比较实用的。这种需求可能比较极端。

mdyblog

红毛樱木 发表于 2017-6-5 23:17
现在的pecmd匹配驱动，默认截取设备唯一ID的前两段，这种做法不科学。
实际使用中需要更复杂的算法。
...

你是说 “硬件ID”和“兼容个ID” 同时同等地参与匹配？是吗？

红毛樱木

mdyblog 发表于 2017-6-6 13:28
你是说 “硬件ID”和“兼容个ID” 同时同等地参与匹配？是吗？

是的，整行匹配到了，说明这个inf才有效

mdyblog

红毛樱木 发表于 2017-6-6 13:30
是的，整行匹配到了，说明这个inf才有效

“整行匹配到” 这个太严了。实际只有前最多2段有用。后面的一般没用，一般就正对硬件的说明，和驱动没关系。

mdyblog

红毛樱木 发表于 2017-6-6 13:30
是的，整行匹配到了，说明这个inf才有效

你前面说 DEVI 目录无效， 是NT5还是NT6啊？什么系统？
NT5有可能。 DEVI  CAB自己对临时解压驱动文件做了优化处理。 如果是用户制定的文件，不能随便动人家的文件。

红毛樱木

mdyblog 发表于 2017-6-6 13:35
“整行匹配到” 这个太严了。实际只有前最多2段有用。后面的一般没用，一般就正对硬件的说明，和驱动没关 ...

这个我研究了好久。
有整行匹配到的INF才可以。你截取的前两段，如果没有整行匹配，windows也不会去安装这个inf的

红毛樱木

mdyblog 发表于 2017-6-6 13:38
你前面说 DEVI 目录无效， 是NT5还是NT6啊？什么系统？
NT5有可能。 DEVI  CAB自己对临时解压驱动文件做 ...

DEVI目录无效是nt6无效。nt5下没这么用过，不清楚。

mdyblog

红毛樱木 发表于 2017-6-6 13:46
这个我研究了好久。
有整行匹配到的INF才可以。你截取的前两段，如果没有整行匹配，windows也不会去安装 ...

如果没有整行匹配，windows也不会去安装这个inf的
什么版本的WIndows？NT5不会吧。NT6都这样吗？

是不是还有“强制安装”一说？此时不需要“整行匹配”？

红毛樱木

mdyblog 发表于 2017-6-6 15:19
如果没有整行匹配，windows也不会去安装这个inf的
什么版本的WIndows？NT5不会吧。NT6都这样吗？

“强制安装”本身就不是规范的安装。
可以本机驱动测试下。
改下INF内容试试

mdyblog

红毛樱木 发表于 2017-6-6 15:43
“强制安装”本身就不是规范的安装。
可以本机驱动测试下。
改下INF内容试试

作为PE工具，必须把“强制安装”当做“正常安装”。毕竟很多时候，就是用“能用的驱动”驱动起来就可以。
严丝合缝，那的多少驱动包，不适合PE。

完全配合，设一个足够大的级别即可，比如10000， 总没有超过10000的吧。

红毛樱木

mdyblog 发表于 2017-6-6 16:51
作为PE工具，必须把“强制安装”当做“正常安装”。毕竟很多时候，就是用“能用的驱动”驱动起来就可以。 ...

这种说法可能“适用”nt5，但在nt6下已经不适用了。

hhh333

M大好，该是出国回来了吧。那肯定海龟了。咱们土鳖还在继续玩PE。
DEVI说明里的功能有的用不起如DEVI　＊.inf /s搜子目录安装功能用不起，再一个就是DEVI每次扫描效率低下的问题。希望有一个强劲的DEVI功能！
1、希望将已知bug修正一下；
2、强化DEVI功能：
①解决每次扫描硬件功能
②为了加快安装效率可不可以引入索引功能：如做一个小工具提取inf中的驱动ID做成索引，安装时DEVI不用再读每个INF文件来比对，直接查找索引。也即有些工作可以在制作驱动包时就做好。
③对安装次数进行自定义，如单设备可以只找到第一个匹配的，双设备可以找两个，ALL可以找所有的。

mdyblog

hhh333 发表于 2017-6-6 17:22
M大好，该是出国回来了吧。那肯定海龟了。咱们土鳖还在继续玩PE。
DEVI说明里的功能有的用不起如DEVI　＊. ...

“引入索引功能”  这个好，的确能大大加快。

mdyblog

hhh333 发表于 2017-6-6 17:22
M大好，该是出国回来了吧。那肯定海龟了。咱们土鳖还在继续玩PE。
DEVI说明里的功能有的用不起如DEVI　＊. ...

③对安装次数进行自定义，如单设备可以只找到第一个匹配的，双设备可以找两个，ALL可以找所有的。
-------------------------------
没怎么明白 什么意思？

mdyblog

红毛樱木 发表于 2017-6-6 16:52
这种说法可能“适用”nt5，但在nt6下已经不适用了。

那就NT6默认设为完整匹配，且可 配合兼容ID

mdyblog

hhh333 发表于 2017-6-6 17:22
M大好，该是出国回来了吧。那肯定海龟了。咱们土鳖还在继续玩PE。
DEVI说明里的功能有的用不起如DEVI　＊. ...

DEVI说明里的功能有的用不起如DEVI　＊.inf /s搜子目录安装功能用不起
--------------------
按说已经有了，也测试过， 到时可能的远程到你们的机器上，看看问题到底出在哪儿？