请问下有没有办法用批处理或者命令行小程序确定系统引导分区？

liuzhaoyzz · 发表于 2021-1-15 11:59:27

本帖最后由 liuzhaoyzz 于 2021-1-15 12:09 编辑

dos时代菜鸟发表于 2021-1-15 11:35

辛苦了，谢谢!晚点回去测试下。

试了下从FAT32分区启动，结果出错了。

dos时代菜鸟 · 发表于 2021-1-15 12:33:51

本帖最后由 dos时代菜鸟于 2021-1-15 12:37 编辑

liuzhaoyzz 发表于 2021-1-15 11:59
辛苦了，谢谢!晚点回去测试下。

试了下从FAT32分区启动，结果出错了。

是什么系统 xp win7 8 10 pe ?

估计是 xp

直接双击批处理，而不是例子，看看啥情况。

dos时代菜鸟 · 发表于 2021-1-15 12:39:13

本帖最后由 dos时代菜鸟于 2021-1-15 12:46 编辑

liuzhaoyzz 发表于 2021-1-15 11:59
辛苦了，谢谢!晚点回去测试下。

试了下从FAT32分区启动，结果出错了。

dpy.361.7z (2.5 KB, 下载次数: 135)

在 xp 系统不运行 bcdedit 的情况下，进行了下调整，有一个变量没有赋值，导致不对 diskpart 数据进行分析。
已经更正。

liuzhaoyzz · 发表于 2021-1-15 12:49:17

dos时代菜鸟发表于 2021-1-15 12:33
是什么系统 xp win7 8 10 pe ?

估计是 xp

系统是UEFI WIN7

dos时代菜鸟 · 发表于 2021-1-15 12:56:33

本帖最后由 dos时代菜鸟于 2021-1-15 13:23 编辑

liuzhaoyzz 发表于 2021-1-15 12:49
系统是UEFI WIN7

xp 下 cmd 中运行 ver 显示是 5.x ?
win7 是 6.x ? 记不清了，可能设置大了，

dpy.4.7z (2.51 KB, 下载次数: 12)

liuzhaoyzz · 发表于 2021-1-15 13:24:41

本帖最后由 liuzhaoyzz 于 2021-1-15 13:27 编辑

dos时代菜鸟发表于 2021-1-15 12:56
xp 下 cmd 中运行 ver 显示是 5.x ?
win7 是 6.x ? 记不清了，可能设置大了，

ver|find " 5."&& goto :XP03
ver|find "6.1."&& goto :win7
ver|find "6.2."&& goto :win810
ver|find "6.3."&& goto :win810
ver|find "6.4."&& goto :win810
ver|find "10.0."&& goto :win810

哦，这个版本正常了！

另外想问下，32位的第三方资源管理器里面，无法直接运行这个批处理，提示：
_Windows_CMD_version:6
Components is not found : bcdedit.exe
请按任意键继续. . .
可有办法？
64位的就可以。

dos时代菜鸟 · 发表于 2021-1-15 13:43:41

本帖最后由 dos时代菜鸟于 2021-1-15 13:45 编辑

liuzhaoyzz 发表于 2021-1-15 13:24
ver|find " 5."&& goto :XP03
ver|find "6.1."&& goto :win7
ver|find "6.2."&& goto :win810

脚本会找 c:\windows\system32\bcdedit.exe
如果版本 >=6 而又没有这个文件，就会提示这个了。
同样的没有 diskpart 或者 chcp 都是这个提示。

liuzhaoyzz · 发表于 2021-1-15 13:45:48

dos时代菜鸟发表于 2021-1-15 13:43
脚本会找 c:\windows\system32\bcdedit.exe
如果版本 >=6 而又没有这个文件，就会提示这个了。

c:\windows\system32\bcdedit.exe是一直存在的，64位操作系统里面，32位的第三方文件管理器只能调用32位的cmd，一般地来说32位的程序只能调用c:\windows\syswow64下面的程序，根本无法调用c:\windows\system32里面的程序，这是文件重定向机制决定的。

CodeHz · 发表于 2021-1-15 13:47:45

liuzhaoyzz 发表于 2021-1-15 13:45
c:\windows\system32\bcdedit.exe是一直存在的，64位操作系统里面，32位的第三方文件管理器只能调用32位 ...

莫慌，重定向可以再重定向回来的，访问%windir%/sysnative就是原系统的system32(

liuzhaoyzz · 发表于 2021-1-15 14:00:42

本帖最后由 liuzhaoyzz 于 2021-1-15 14:20 编辑

CodeHz 发表于 2021-1-15 13:47
莫慌，重定向可以再重定向回来的，访问%windir%/sysnative就是原系统的system32(

这个%windir%/sysnative用起来感觉比较麻烦，如果是64位的cmd环境这个%windir%/sysnative就出出错；如果32位的cmd环境这个%windir%/sysnative调用是对的；双击批处理又难以知道这个这个bat是被32位的还是64位的cmd调用，因为可能是从64位的windows资源管理器里面运行，也有可能是从32位的第三方的资源管理器中运行的，我用32位的日本人写的MDIE第三方多标签文件管理器有十年了，从来没有想过要更换。（total command、Q-dir、explorer++、QTTabbar、directory opus、clover、百页窗、xyplorer统统不喜欢）

你写的shellexecuteex，好像不支持xp，还要提前判断，也有点麻烦，因为事前我不知道用户倒底是什么操作系统，如果直接双击基于shellexecuteex写的批处理就会出错。
shellexecuteex /wow64 /show 5 cmd.exe
解除 WoW64 文件系统重定向的情况下运行cmd

dos时代菜鸟 · 发表于 2021-1-15 14:01:20

liuzhaoyzz 发表于 2021-1-15 13:45
c:\windows\system32\bcdedit.exe是一直存在的，64位操作系统里面，32位的第三方文件管理器只能调用32位 ...

用你这个 32位文件管理器，打开cmd 看下他的 ComSpec 是多少？
我们可以改下路径，到cmd 的解析路径找需要的文件。而不是固定到 system32

CodeHz · 发表于 2021-1-15 14:05:03

dos时代菜鸟发表于 2021-1-15 14:01
用你这个 32位文件管理器，打开cmd 看下他的 ComSpec 是多少？
我们可以改下路径，到cmd 的解析路径找 ...

cmd当然也会是32位重定向的版本（（

CodeHz · 发表于 2021-1-15 14:05:31

liuzhaoyzz 发表于 2021-1-15 14:00
这个%windir%/sysnative用起来感觉比较麻烦，如果是64位的cmd环境这个%windir%/sysnative就出出错；如果3 ...

我的意思是可以通过检测sysnative目录的存在性来判断（

dos时代菜鸟 · 发表于 2021-1-15 14:07:28

本帖最后由 dos时代菜鸟于 2021-1-15 14:10 编辑

CodeHz 发表于 2021-1-15 14:05
cmd当然也会是32位重定向的版本（（

这是改过的

dpy.41.7z (2.57 KB, 下载次数: 10)

用下面代码的 cmd 在32位文件管理器里运行下，看啥结果。

@echo off
setlocal ENABLEDELAYEDEXPANSION
for /f %%x in ("%ComSpec%") do set "cmd_path=%%~dpx"
echo cmd_path=!cmd_path!
pause

复制代码

liuzhaoyzz · 发表于 2021-1-15 14:10:38

dos时代菜鸟发表于 2021-1-15 14:01
用你这个 32位文件管理器，打开cmd 看下他的 ComSpec 是多少？
我们可以改下路径，到cmd 的解析路径找 ...

我用了奇技淫巧解决32位的第三方资源管理器下面调用c:\widnows\system32\下面的程序，就是用创建软链接，然后修改cmd解释器的指向的办法解决问题的。创建软链接之后，ComSpec=C:\Windows\system32\cmd.exe

@echo off
rem 因为在MDIE里面双击bat/cmd文件默认调用的是32位的c:\windows\syswow64\cmd.exe，可能会导致批处理运行异常，因此优先改用64位的c:\windows\system32\cmd.exe。xp和32位系统不存在此问题，直接跳过。
ver|find " 5."&& goto :next
if /i %PROCESSOR_IDENTIFIER:~0,3%==x86 goto :next
md c:\windows\Sysnative 1>nul 2>nul
mklink c:\windows\Sysnative\cmd.exe c:\windows\System32\cmd.exe
reg add "HKCR\batfile\shell\open\command" /ve /d "C:\windows\sysnative\cmd.exe /c \"%%1\" %%*" /f
reg add "HKCR\cmdfile\shell\open\command" /ve /d "C:\windows\sysnative\cmd.exe /c \"%%1\" %%*" /f
:next

CodeHz · 发表于 2021-1-15 14:13:56

dos时代菜鸟发表于 2021-1-15 14:07
这是改过的

看图就很明确了

wow64重定向就是让你看起来像是在真的32位环境跑

liuzhaoyzz · 发表于 2021-1-15 14:15:55

dos时代菜鸟发表于 2021-1-15 14:07
这是改过的

32位的文件管理器，很容易重现，比如你把你的批处理发给qq上面的任意一位好友，然后从qq的文件管理器里面双击这个批处理，这时候就是在64位系统里面调用的32位的文件管理器。在网络浏览器比如搜狗浏览器的下载窗口下载的批处理双击的时候调用的也是64位系统里面的32位的文件管理器。

BCDedit did not find BCD_VOL！不知道是不是正常的？

CodeHz · 发表于 2021-1-15 14:18:01

liuzhaoyzz 发表于 2021-1-15 14:15
32位的文件管理器，很容易重现，比如你把你的批处理发给qq上面的任意一位好友，然后从qq的文件管理器里面 ...

其实主动调用 SysWoW64 里的cmd就是跑的32位的cmd了（（可以通过ProcExp看到访问的相关目录全都是重定向的）

dos时代菜鸟 · 发表于 2021-1-15 14:18:44

liuzhaoyzz 发表于 2021-1-15 14:10
我用了奇技淫巧解决32位的第三方资源管理器下面调用c:\widnows\system32\下面的程序，就是用创建软链接， ...

可以通过判断变量 %ProgramFiles% 来判断，如果是带 (x86) ，一定是 64位下的32位cmd

dos时代菜鸟 · 发表于 2021-1-15 14:30:09

liuzhaoyzz 发表于 2021-1-15 14:15
32位的文件管理器，很容易重现，比如你把你的批处理发给qq上面的任意一位好友，然后从qq的文件管理器里面 ...

cmd_path.7z (270 Bytes, 下载次数: 6)
先看看这个方法能不能判断出

dos时代菜鸟 · 发表于 2021-1-15 14:41:03

本帖最后由 dos时代菜鸟于 2021-1-15 14:49 编辑

CodeHz 发表于 2021-1-15 14:13
看图就很明确了

wow64重定向就是让你看起来像是在真的32位环境跑

但是 %programfiles% 就不一样，他总不至于在32位下去调用 64的程序去吧，
看这个变量，就知道了。

dpy.42.7z (2.61 KB, 下载次数: 9)

因为 64位系统下的 sysWOW64 里面没有 32位的 bcdedit.exe
所以改进了一下

liuzhaoyzz · 发表于 2021-1-15 14:44:12

dos时代菜鸟发表于 2021-1-15 14:18
可以通过判断变量 %ProgramFiles% 来判断，如果是带 (x86) ，一定是 64位下的32位cmd

哦，这个办法可行。

liuzhaoyzz · 发表于 2021-1-15 14:49:39

dos时代菜鸟发表于 2021-1-15 14:41
但是 %programfiles% 就不一样，他总不至于在32位下去调用 64的程序去吧，
看这个变量，就知道了。

...

确实64位操作系统里面，微软只提供了64位的bcdedit，位于c:\windows\system32\bcdedit.exe。

32位的操作系统里面微软只提供了32位的bcdedit,位于c:\windows\system32\bcdedit.exe

dos时代菜鸟 · 发表于 2021-1-15 14:51:37

本帖最后由 dos时代菜鸟于 2021-1-15 14:57 编辑

liuzhaoyzz 发表于 2021-1-15 14:49
确实64位操作系统里面，微软只提供了64位的bcdedit，位于c:\windows\system32\bcdedit.exe。

这里面的情况还真多。

改进了一下。

这样64位下的32位调用，就不能通过 bcdedit 来获取目标分区了，就有概率获取不到数据。
不过这总比运行不了要强一些。

或者自备一套 bcdedit+diskpart+chcp ,但这样做体积就大了。

liuzhaoyzz · 发表于 2021-1-15 14:59:51

dos时代菜鸟发表于 2021-1-15 14:30
先看看这个方法能不能判断出

你这个判断不对，在XP下面运行，结果是当前环境是64位系统下的64位环境。
xp下面，%ProgramFiles%=C:\Program Files

CodeHz · 发表于 2021-1-15 15:03:48

dos时代菜鸟发表于 2021-1-15 14:51
这里面的情况还真多。

改进了一下。

思考了以下你可以先尝试 %windir%\sysnative\bcdedit ，失败再尝试 %windir%\system32\bcdedit ，再不行就报告
应该就可以了（

liuzhaoyzz · 发表于 2021-1-15 15:06:56

CodeHz 发表于 2021-1-15 15:03
思考了以下你可以先尝试 %windir%\sysnative\bcdedit ，失败再尝试 %windir%\system32\bcdedit ，再不行 ...

64位 xp 根本不用考虑吧。。。这东西不兼容的地方多了

不是考虑64位的xp啊，是32位xp下面，运行dos时代菜鸟的批处理，显示结果却是“当前环境是64位系统下的64位环境”。
我没安装过64位的XP。

dos时代菜鸟 · 发表于 2021-1-15 15:09:27

本帖最后由 dos时代菜鸟于 2021-1-15 15:10 编辑

liuzhaoyzz 发表于 2021-1-15 15:06
不是考虑64位的xp啊，是32位xp下面，运行dos时代菜鸟的批处理，显示结果却是“当前环境是64位系统下的6 ...

xp 下这个已经不重要了，因为 xp 下根本没有 bcdedit 也就不用考虑这个问题
判断版本 >=6 的，才会去判断是不是 64下的 32 ，如果是，就不找 bcdedit.
而如果 <6 的版本，直接就不会去找 bcdedit

CodeHz · 发表于 2021-1-15 15:09:31

liuzhaoyzz 发表于 2021-1-15 15:06
不是考虑64位的xp啊，是32位xp下面，运行dos时代菜鸟的批处理，显示结果却是“当前环境是64位系统下的6 ...

哦，也对，不过判断架构不是可以用 PROCESSOR_ARCHITECTURE 吗（
所以先检测架构，是32位再检测WoW

CodeHz · 发表于 2021-1-15 15:11:33

dos时代菜鸟发表于 2021-1-15 15:09
xp 下这个已经不重要了，因为 xp 下根本没有 bcdedit 也就不用考虑这个问题

不是，你这个逻辑的问题在于，纯32位的win7，8，8.1，10的ProgramFiles变量也是没x86的（

		自动登录	找回密码
密码			注册

请问下有没有办法用批处理或者命令行小程序确定系统引导分区？

点评

点评

点评

点评

点评

点评

点评

点评

点评

点评