找回密码
 注册
搜索
系统gho:最纯净好用系统下载站投放广告、加入VIP会员,请联系 微信:wuyouceo
楼主: dos时代菜鸟

diskpart shell ,用 pecmd 给 diskpart 做个外壳 ver:1.29.3

   火... [复制链接]
发表于 2019-7-23 03:57:42 | 显示全部楼层
谢谢分享
回复

使用道具 举报

 楼主| 发表于 2019-7-23 11:26:44 | 显示全部楼层
最新测试 1.20.2

改进了 硬盘分区序列 获取 的方法,用 pecmd 使 diskaprt 驻留进程,随时传递给其命令,然后获取其命令结果。
减少 diskpart 频繁调取 成本。
回复

使用道具 举报

 楼主| 发表于 2019-7-23 20:28:15 | 显示全部楼层
2019.07.23

1.20.4
改进启动和数据刷新 模块,启动和刷新数据时 显示 调取的数据。
因为临时数据文件 不断增加,数据刷新的过程 可能会越来越慢,所以增加一个 “刷新diskpart” 的按钮,用于重新驻留 diskpart 进程,以减小临时文件大小。

1.20.3
用 pecmd 脚本取代 parts.cmd ,实现一次运行 diskpart 驻留进程并等待命令运行,进而节省 diskpart 的调用成本。
因为采用 pecmd+diskpart 获取硬盘分区序列,对一些字符定位进行了调整。
改进 硬盘均分 模块中 己算硬盘 大小的算法。
不再需要建立中间脚本,所有命令都传递给真实的diskpart 进程直接运行,所以 用变量取代了 创建dp_script 脚本文件,运行速度更快。
回复

使用道具 举报

发表于 2019-7-23 21:14:28 | 显示全部楼层
下载收藏谢谢!
请教,若硬盘分c.d.e.f.4个区,系统在c盘,选中d盘,删除,然后退出工具,硬盘c(系统).e.f.是否不受影响?

点评

应该不会受影响,不过,你为什么要这么做呢? d盘删掉了,硬盘就有一块空间没有分配分区,就相当于空闲着浪费了。为啥不把它格式化呢?  详情 回复 发表于 2019-7-23 21:21
回复

使用道具 举报

 楼主| 发表于 2019-7-23 21:21:17 | 显示全部楼层
2019hhh 发表于 2019-7-23 21:14
下载收藏谢谢!
请教,若硬盘分c.d.e.f.4个区,系统在c盘,选中d盘,删除,然后退出工具,硬盘c(系统).e.f.是否不 ...

应该不会受影响,不过,你为什么要这么做呢?
d盘删掉了,硬盘就有一块空间没有分配分区,就相当于空闲着浪费了。为啥不把它格式化呢?
回复

使用道具 举报

发表于 2019-7-23 21:26:37 | 显示全部楼层
不会这样做,就是疑问一下.工具很好用,能否放单文件版?

点评

源码 不打包,方便随时改进。 要单文件的,可以自己做。  详情 回复 发表于 2019-7-23 21:32
回复

使用道具 举报

 楼主| 发表于 2019-7-23 21:32:41 | 显示全部楼层
2019hhh 发表于 2019-7-23 21:26
不会这样做,就是疑问一下.工具很好用,能否放单文件版?

源码 不打包,方便随时改进。
要单文件的,可以自己做。
回复

使用道具 举报

发表于 2019-7-23 22:35:54 | 显示全部楼层
屏幕截图(270).png

正在加载中


捕获.PNG

对比一下



如果不是为了测试,建议最终关闭加载过程显示,仅显示最上面那一行字就可以了,感觉显示会严重影响效率。
回复

使用道具 举报

发表于 2019-7-23 23:03:15 | 显示全部楼层
本帖最后由 datbik189 于 2019-7-23 23:11 编辑

感觉是初次启动diskpart时间久,我的WIN10机子经过测试,要300-2500ms,有时快,有时慢。

http://bbs.wuyou.net/forum.php?m ... 2NTl8MHwyMDU0MDI%3D

20190723230427-forum.jpg
回复

使用道具 举报

 楼主| 发表于 2019-7-24 06:01:27 | 显示全部楼层
因为为了保险起见 脚本设计成 每 50ms 轮询一次临时文件来判断上一条指令是否运行完毕,来决定运行下一条指令,所以会慢一些,可以在 diskpart2x.wcs 的 第 32行 envi wait_n=50 改为 envi wait_n=5 ,应该会快一些。

启动时 显示的 数据 是每 200ms 读取 临时文件信息,根 diskpart 运行是并行的,应该不会影响指令运行速度。

速度 还与 硬盘临时文件的大小、存储、硬盘个数、分区个数等有一定关系,尤其是 硬盘个数和分区个数,这个直接决定了 探测指令的个数。
而 pecmd 读取临时文件时,因为文件体积的增加,也会变慢。
回复

使用道具 举报

 楼主| 发表于 2019-7-24 07:51:55 | 显示全部楼层
本帖最后由 dos时代菜鸟 于 2019-7-24 07:58 编辑

刚 增加了一个显示 数据载入时间的 文本签

这个不同于 diskpart /s 的方式运行脚本,因为 需要对临时文件进行轮询 确定 diskpart 及其每一条指令 已经运行了,这个是需要耗费时间的,但是对diskpart 本身的资源应该是 节省了的。而且以后 脚本中 要运行一些 指令,如果不重新 刷新数据,这些指令的运行也应该是 节省成本的,

如图:
如此硬盘分区结构的获取也不过10秒,多次运行 消耗时间出入不大。
捕获.PNG
回复

使用道具 举报

 楼主| 发表于 2019-7-24 13:01:09 | 显示全部楼层
再次更新 1.20.8
调整 获取硬盘分区序列的算法,减少diskpart指令个数,加快获取速度。
优化时间算法。
增加 退出 按钮,防止 形成 pecmd 死进程。
回复

使用道具 举报

 楼主| 发表于 2019-7-24 13:26:42 | 显示全部楼层
sshot-1.png
这回 加载 速度 也快了不少。
回复

使用道具 举报

发表于 2019-7-24 15:59:20 | 显示全部楼层

牛,10秒太夸张了. 我运行你的脚本是1.5秒, 这才是让人愉悦的速度.

建议时间标签换成两种, 一种是diskpart的启动时间,一种是脚本运行的时间, 这样才能判断是diskpart慢, 还是分析脚本慢.

时常调用diskpart的脚本, 建议做成命令块, 这将大大减少工作量.

附件中的文件:

#997:
为测试版本, 需人工输入.

#998:
为命令行版本, 自动化,返回以下的变量值.
&DISKPART_WID   --- 返回窗口的WID值
&DISKPART-FILE   --- 返回临时文件的全路径名称
&RET_F                --- 返回运行的历史记录
&RET_L                --- 返回最新命令运行的记录

123.jpg

DISKPART_TEST.EXE

1.01 MB, 下载次数: 4

点评

现在的问题是临时文件越大,返回时间就越长。 而这个确实必须要承受的,因为我们要 读取临时文件 判断 指令是否运行完毕 并获取 指令运行结果。 如果 pecmd 能够 让 diskpart 的输出 指向一个内存 位置 就好了。  详情 回复 发表于 2019-7-24 16:10
回复

使用道具 举报

 楼主| 发表于 2019-7-24 16:10:32 | 显示全部楼层
本帖最后由 dos时代菜鸟 于 2019-7-24 16:29 编辑
datbik189 发表于 2019-7-24 15:59
牛,10秒太夸张了. 我运行你的脚本是1.5秒, 这才是让人愉悦的速度.

建议时间标签换成两种, 一种是diskp ...


现在的问题是临时文件越大,返回时间就越长。
而这个确实必须要承受的,因为我们要 读取临时文件 判断 指令是否运行完毕 并获取 指令运行结果。

而 向 diskpart 窗口传递指令 需要用 code 进行转化,这个也是费时的一个地方。

如果 pecmd 能够 让 diskpart 的输出 指向一个内存 位置 就好了。或者说 把临时文件放入内存。

刚发现一个脚本问题,就是 刷新 diskpart 进程 时,主窗口 是可操作的,此时如果用户 操作窗口,就可能发生问题,虽然 刷新 diskpart 进程只有一秒。有的 奇葩电脑 diskpart 启动就会很慢,有的甚至 几十秒,这样 就给用户机会去操作 主窗口了。所以 还是 改进了一下。

还有 发现 造成 pecmd 死进程的一个原因,可能是 我 再没有退出 pecmd 的情况下 修改编辑了正在调用的脚本。

点评

我运行了100遍 sel disk 0 + detail disk, 花了 135 ms. 防止误操作,只能是你在脚本中临时禁用某些控件. envi^ envimode=1 load #998 //启动diskpart date &t1 uptime load #999*命令_数字循环 &V 1 1 1  详情 回复 发表于 2019-7-24 16:29
回复

使用道具 举报

发表于 2019-7-24 16:29:53 | 显示全部楼层
本帖最后由 datbik189 于 2019-7-24 16:46 编辑
dos时代菜鸟 发表于 2019-7-24 16:10
现在的问题是临时文件越大,返回时间就越长。
而这个确实必须要承受的,因为我们要 读取临时文件 判断 ...



我运行了100遍 sel disk 0 + detail disk, 花了 15303 ms.

防止误操作,只能是你在脚本中临时禁用某些控件.

envi^ envimode=1
load #998  //启动diskpart
date &tt1 uptime   //开始计时
load #999*命令_数字循环 &V 1 1 100 //生成数字1~100
forx * %&V%,&V1,
{*
set. &V_=sel disk 0 \n detail disk
load #998 &V_
}
date &tt2 uptime
calc &tt=%&tt2%-%&tt1%   //结束计时
mess %&ret_f%\n%&ret_l%@耗时 %&tt% ms
kill diskpart

123.jpg

点评

可能跟 envi^ envimode=0 有一定关系 我脚本中大量运行 %% 套 %% 的方式调用变量,不知道 envi^ envimode=0 模式下 怎么用 ~ 解释 多个% 嵌套解释的问题。 窗口控件已经 不能再减啥了,其他窗口的控件 都有功能  详情 回复 发表于 2019-7-24 17:03
回复

使用道具 举报

 楼主| 发表于 2019-7-24 17:03:08 | 显示全部楼层
本帖最后由 dos时代菜鸟 于 2019-7-24 17:06 编辑
datbik189 发表于 2019-7-24 16:29
我运行了100遍 sel disk 0 + detail disk, 花了 15303 ms.

防止误操作,只能是你在脚本中临时禁用 ...


可能跟 envi^ envimode=0 有一定关系
我脚本中大量运行 %% 套 %% 的方式调用变量,不知道 envi^ envimode=1 模式下 怎么用 ~ 解释 多个% 嵌套解释的问题。

窗口控件已经 不能再减啥了,其他窗口的控件 都有功能跟着呢。

你把
result.txt 先存一些内容进去,比如一千行数据,然后把
diskpart >result.txt,变成 diskpart >>result.txt,再看看 ,肯定要更耗时,
这个 pecmd 读取文件时间 取决于 文件的大小。要是只是简单的 模拟 diskpart 的界面操作,并没有什么感觉。但是如果 用在我的这个 功能脚本 上,需要 在每次 Diskpart 指令结束 重新分析获取整个硬盘分区序列并取数据。就会越来越费时间。

关键就是 pecmd 读取文件 和判断 指令运行情况 这方面 费时间。某种程度上,还不如用 cmd 获取硬盘数据来的快了。

我这电脑配置也低,本身速度就上不来。

点评

ENVI^ ENVIMODE=0 是 PECMD4.0模式, 贪婪模式, 不能在%里面套用%. 这个应该不影响速度的. 临时禁止窗口: ENVI @WIN1.VISIBLE=0 //窗口不可见 ENVI @WIN1.ENABLE=0 //窗口不可用 运行了 3 次 50 遍 sel d  详情 回复 发表于 2019-7-24 17:32
回复

使用道具 举报

发表于 2019-7-24 17:32:58 | 显示全部楼层
本帖最后由 datbik189 于 2019-7-24 17:37 编辑
dos时代菜鸟 发表于 2019-7-24 17:03
可能跟 envi^ envimode=0 有一定关系
我脚本中大量运行 %% 套 %% 的方式调用变量,不知道 envi^ envim ...



ENVI^ ENVIMODE=0 是 PECMD4.0模式, 贪婪模式, 不能在%里面套用%.
这个应该不影响速度的.

ENVI^ ENVIMODE=1 是 标准模式, ^SET &V=%%%~1%%或者 ^^^SET &V=%%%~1%%
(一个^就解释一遍)

临时禁止窗口:
ENVI @WIN1.VISIBLE=0 //窗口不可见
ENVI @WIN1.ENABLE=0 //窗口不可用

运行了 3 次 50 遍 sel disk 0 + detail disk,是一遍比一遍慢.

办法是检测文本的行数,大于500行,重启DISKPART?

1.jpg
2.jpg
3.jpg

点评

嗯 这个耗时 的 临时文件模式,根电脑本身速度也有关系,我要是这个情况 估计嘚半分钟。 那个 %% 套 %% 的我的那个脚本就在 用有啊。  详情 回复 发表于 2019-7-24 17:48
回复

使用道具 举报

 楼主| 发表于 2019-7-24 17:48:05 | 显示全部楼层
datbik189 发表于 2019-7-24 17:32
ENVI^ ENVIMODE=0 是 PECMD4.0模式, 贪婪模式, 不能在%里面套用%.
这个应该不影响速度的.

嗯 这个耗时 的 临时文件模式,根电脑本身速度也有关系,我要是这个情况 估计嘚半分钟。

那个 %% 套 %% 的我的那个脚本就在  用有啊。

点评

我的电脑也很烂, I3-8100 3.6 GHz ,内存 4G, 集显.  详情 回复 发表于 2019-7-24 17:59
回复

使用道具 举报

发表于 2019-7-24 17:59:41 | 显示全部楼层
dos时代菜鸟 发表于 2019-7-24 17:48
嗯 这个耗时 的 临时文件模式,根电脑本身速度也有关系,我要是这个情况 估计嘚半分钟。

那个 %% 套 % ...


我的电脑也很烂, I3-8100 3.6 GHz ,内存 4G, 集显.

点评

所以 在我这个脚本里面 干脆就是用户 每运行一组 diskpart 后需要刷新 硬盘分区数据的时候,就 重新来一个 diskpart 进程。这样依赖,还要先把原来的关了,这个关闭的过程也耗时间。 来来回回的,唯一节省点儿的就是  详情 回复 发表于 2019-7-24 18:10
回复

使用道具 举报

 楼主| 发表于 2019-7-24 18:10:57 | 显示全部楼层
datbik189 发表于 2019-7-24 17:59
我的电脑也很烂, I3-8100 3.6 GHz ,内存 4G, 集显.


所以 在我这个脚本里面 干脆就是用户 每运行一组 diskpart 后需要刷新 硬盘分区数据的时候,就 重新来一个 diskpart 进程。这样,还要先把原来的diskpart关了,这个关闭的过程也耗时间。 来来回回的,唯一节省点儿的就是 运行 一组组的 diskpart 指令的时候 是在已有的 diskpart 进程中运行的,要不是考虑 这样可以减少 diskpart 的调用次数,我都不想用这个 办法了。

还有就是 那些 本来启动 diskpart 就很慢的情况下,一次启动了 diskpart 就尽量保持着这个 diskpart 的进程干更多的事情,这样才划算,所以才考虑 这么个办法,让 diskpart 驻留到 进程中由 pecmd 来控制的。

点评

有个思路,不知行不行,明天有空时弄弄再测下。 开始直接运行2个DISKPART,一个用着,一个备用。当其中一个重起,一个还能用。  详情 回复 发表于 2019-7-24 19:09
回复

使用道具 举报

发表于 2019-7-24 19:09:05 来自手机 | 显示全部楼层
dos时代菜鸟 发表于 2019-7-24 18:10
所以 在我这个脚本里面 干脆就是用户 每运行一组 diskpart 后需要刷新 硬盘分区数据的时候,就 重新来 ...


有个思路,不知行不行,明天有空时弄弄再测下。

开始直接运行2个DISKPART,一个用着,一个备用。当其中一个重起,一个还能用。

点评

可以考虑试试看。  详情 回复 发表于 2019-7-24 20:47
回复

使用道具 举报

 楼主| 发表于 2019-7-24 20:47:08 | 显示全部楼层
datbik189 发表于 2019-7-24 19:09
有个思路,不知行不行,明天有空时弄弄再测下。

开始直接运行2个DISKPART,一个用着,一个备用。当 ...

可以考虑试试看。

点评

测试了一下,脚本运行速度没什么变化, 没办法了. 时间都是约 14 秒. [attachimg]397604[/attachimg] [attachimg]397605[/attachimg]  详情 回复 发表于 2019-7-25 15:03
从上面的图片,发现一个奇怪的问题,运行同样的命令sel disk 0 + detail disk,150遍后时间没有显注增加,我怀疑我的脚本计算总时那出问题了,而不是因为临时文件太长了导致时长的增加。 运行了1遍:19+22=41ms  详情 回复 发表于 2019-7-24 21:36
我那有现成的命令块,明早如果没事,我改下命令块。 我觉得应该可以自动切换,新的diskpart 重启好了,自动切换到新的diskpart,并重启另一个,如此循环,用线程。  详情 回复 发表于 2019-7-24 21:00
回复

使用道具 举报

发表于 2019-7-24 21:00:31 | 显示全部楼层


我那有现成的命令块,明早如果没事,我改下命令块。

我觉得应该可以自动切换,新的diskpart 重启好了,自动切换到新的diskpart,并重启另一个,如此循环,用线程。
回复

使用道具 举报

 楼主| 发表于 2019-7-24 21:28:20 | 显示全部楼层
随机发生  pecmd 僵尸进程。不知为何。
回复

使用道具 举报

发表于 2019-7-24 21:36:59 来自手机 | 显示全部楼层
dos时代菜鸟 发表于 2019-7-24 20:47
可以考虑试试看。


从上面的图片,发现一个奇怪的问题,运行同样的命令sel disk 0 + detail disk,150遍后时间没有显注增加,我怀疑我的脚本计算总时那出问题了,而不是因为临时文件太长了导致时长的增加。

运行了1遍:19+22=41ms
运行了50遍:12+26=38ms
运行了100遍:15+27=42ms
运行了150遍:18+36=54ms
回复

使用道具 举报

发表于 2019-7-25 15:03:27 | 显示全部楼层
本帖最后由 datbik189 于 2019-7-25 17:01 编辑



从测试来看, 建议采取切换WID的办法且不保存历史记录(将 &DISKPART_OLD 改成 &), 获得DISKPART的回显.

测试了一下,脚本运行速度没什么变化, 没办法了.

固定WID 和 切换不同的WID (换DISKPART), 运行100遍 "sel disk 0 + detail disk" 时间都是约 14 秒.

运行了1500次以后, 不保存历史记录(将 &DISKPART_OLD 改成 &), 结果如下:

固定WID: 临时文件有 43508 行,最后一次运行的时间为 217 ms, 总的运行时间 227 秒.

变换WID:  临时文件小于 500 行,最后一次运行的时间为 33 ms, 总的运行时间为 109 秒.

变换WID.jpg
固定WID.jpg
临时文件.jpg

变换WID脚本:

envi^ envimode=1

set-raw &启动副本=thread* -here -tid:&备用tid team wait 50|set &DISKPART_备用WID=|load #998 & &DISKPART_备用WID &DISKPART_备用FILE & &|SET-RET &DISKPART_备用WID=%&DISKPART_备用WID%|SET-RET &DISKPART_备用FILE=%&DISKPART_备用FILE%
team set. &exit=exit\n|load #999*命令_宽字符 &exit

load #998 & &DISKPART_WID &DISKPART_FILE &DISKPART_OLD &DISKPART_NEWS //启动diskpart
%&启动副本%

load #999*命令_数字循环 &num 1 1 100 //生成数字序列
date &t1 uptime
forx * %&num%,&,
{* set. &指令=sel disk 0 \n detail disk
   load #998 &指令 &DISKPART_WID &DISKPART_FILE &DISKPART_OLD &DISKPART_NEWS
   Team read %&DISKPART_file%,**,&V|read -*,-1,&V,&V
   IFEX $[%&V%>500 & %&DISKPART_备用WID%>0],
   {* forx * %&exit%,&V,ENVI @@SENDMSG=%&DISKPART_WID%;0X102;0x%&V%
      Team set &DISKPART_WID=%&DISKPART_备用WID%|set &DISKPART_FILE=%&DISKPART_备用FILE%
      %&启动副本%
    }
}
date &t2 uptime
calc &t=%&t2%-%&t1%
team set. &line=%&DISKPART_OLD%\n%&DISKPART_NEWS%|read -*,-1,&line,&line
mess %&DISKPART_OLD%\n%&DISKPART_NEWS%@耗时 %&t% ms %&line% 行
kill diskpart.exe


1.jpg
2.jpg

DISKPART.7z

985.1 KB, 下载次数: 8

点评

结合我自己的实际情况 按照双 diskpart 进程的想法,也弄了一个。你那个 代码有的地方不适合我这里用。 1.22.0 使用 双 diskpart 进程模式, 一个进程用完一次就 thrd方式 重启并换成另一个,如此往复,保证 su  详情 回复 发表于 2019-7-25 23:02
回复

使用道具 举报

 楼主| 发表于 2019-7-25 15:04:31 | 显示全部楼层
小改动
1.21.4
优化 获取硬盘序列的 部分代码,减少指令条数。
纠正一处因为 使用 evnimode=1 导致的 %% 问题
回复

使用道具 举报

 楼主| 发表于 2019-7-25 23:02:23 | 显示全部楼层
datbik189 发表于 2019-7-25 15:03
从测试来看, 建议采取切换WID的办法且不保存历史记录(将 &DISKPART_OLD 改成 &), 获得DISKPART的回显 ...

结合我自己的实际情况 按照双 diskpart 进程的想法,也弄了一个。你那个 代码有的地方不适合我这里用。

1.22.0
使用 双 diskpart 进程模式,
一个进程用完一次就 thrd方式 重启并换成另一个,如此往复,保证 sub:get_parts 使用的 diskpart 的临时文件是最小的。以此提高效率。
设置diskpart 进程重启的 行数阈值(160行),如果 当前 diskpart 进程对应的临时文件行数超过160 就另开启线程 重启之。

点评

问题解决了就好,原理都一样,剩下就是看测试反馈了。  详情 回复 发表于 2019-7-25 23:32
回复

使用道具 举报

发表于 2019-7-25 23:32:46 来自手机 | 显示全部楼层
dos时代菜鸟 发表于 2019-7-25 23:02
结合我自己的实际情况 按照双 diskpart 进程的想法,也弄了一个。你那个 代码有的地方不适合我这里用。
...


问题解决了就好,原理都一样,剩下就是看测试反馈了。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1|闽公网安备35020302032614号 )

GMT+8, 2026-9-13 11:54

Powered by Discuz! X5.0

© 2001-2026 Discuz! Team.

快速回复 返回顶部 返回列表