无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站广告联系 微信:wuyouceo QQ:184822951
楼主: 2011足迹

native版的mini pecmd测试,添加mount命令--2011-4-4

    [复制链接]
发表于 2011-4-3 23:25:42 | 显示全部楼层
由于以前代码部分丢了,从驱动代码还原的,比较麻烦,在win32环境测试通过,还没有合到NATIVE模式。

由于头文件包含关系很复杂,我封装了一个静态库,导出函数是LaotouMountImage。
和wim sdk里面的WimMountImage原型相同。

DWORD // 返回值为 0 ,表示成功,这个其实就是 NTSTATUS ,为了方便,改了一下。
LaotouMountImage(
    LPWSTR lpszMountPath,// 挂载的路径
    LPWSTR lpszWimFileName,// 挂载的WIM文件名
    DWORD  dwImageIndex,// 索引号
    LPWSTR lpszTempPath // 临时目录路径,为NULL表示只读挂载。
    );

在自己的代码中加入上面的函数定义,就可以像下面这样调用了。
int main(int argc, char* argv[])
{
       printf("%08lX\r\n",LaotouMountImage(L"E:\\DDD",L"E:\\1.WIM",1,NULL));
  return 0;
}

在引用的LIB库里面加上附件里面LaotouWim.lib就可以链接通过。
“卸载函数”等以后有需求再加。
“查询列表的函数”我也不知道怎么实现,虽然也是发送一个消息,但是在哪里接收我也没有研究。

NATIVE编程环境还在调整,我的DDK版本较低。

“足迹”有空就先合进去看看能否使用,这个静态库只调用了ntdll.dll里面的函数,应该没问题的。
我现在测试环境也没有,明天比较忙,后天才可能有空继续搞。

[ 本帖最后由 liulaotou2 于 2011-4-4 00:50 编辑 ]
回复

使用道具 举报

 楼主| 发表于 2011-4-4 00:20:41 | 显示全部楼层
原帖由 liulaotou2 于 2011-4-3 23:25 发表
由于以前代码部分丢了,从驱动代码还原的,比较麻烦,在win32环境测试通过,还没有合到NATIVE模式。

由于头文件包含关系很复杂,我封装了一个静态库,导出函数是LaotouMountImage。
和wim sdk里面的WimMoun ...

试了一下..连接不成功..应该是没有编译成native的..网上搜索了一下..需要用ddk编译才行..
回复

使用道具 举报

发表于 2011-4-4 00:51:03 | 显示全部楼层

回复 #135 2011足迹 的帖子

编译器版本不一致,我尽量抽时间搞一下。
回复

使用道具 举报

 楼主| 发表于 2011-4-4 09:50:22 | 显示全部楼层
原帖由 liulaotou2 于 2011-4-3 23:25 发表
NATIVE编程环境还在调整,我的DDK版本较低。

编译问题请使用check编译环境,这样可以避免那三个警告被当做错误处理
编译脚本请更新为

  1. cls
  2. IF NOT DEFINED MINWIN_SDK_LIB_PATH SET MINWIN_SDK_LIB_PATH=%SDK_LIB_PATH%
  3. build.exe /g /w /M 2 /c /F /y
复制代码

这个脚本修正了找不到nt.lib的问题..ddk没有设置环境变量MINWIN_SDK_LIB_PATH导致nt.lib的路径变成了\nt.lib
回复

使用道具 举报

发表于 2011-4-4 10:07:30 | 显示全部楼层

回复 #137 2011足迹 的帖子

我换了一个新的DDK提示nt.lib有问题,正准确去下载最新版本呢,看到这个帖子就解决了。
回复

使用道具 举报

 楼主| 发表于 2011-4-4 10:27:42 | 显示全部楼层
原帖由 liulaotou2 于 2011-4-4 10:07 发表
我换了一个新的DDK提示nt.lib有问题,正准确去下载最新版本呢,看到这个帖子就解决了。

刚开始就发现这个问题了..一直没找到原因...昨天研究ddk的makefile.new才找到原因..
以前的解决办法是把nt.lib复制到源码所在盘的根目录..
回复

使用道具 举报

发表于 2011-4-4 10:44:22 | 显示全部楼层
用DDK重新编译了。
压缩包包含如下文件,直接解压到nativeshell目录就可以。
│  b.bat
│  sources
│  
├─inc
│      laotou.h
│      
└─lib
        laotouwim.lib
引用的时候 #include "laotou.h" 就可以。
我在main.c用比较粗暴的方法调用 LaotouMountImage 链接通过,应该没问题了。
LaotouMountImage(L"E:\\DDD",L"E:\\1.WIM",1,NULL);

跟nativeshell的融合你自己做吧。

laotoulib.rar

7.95 KB, 下载次数: 64, 下载积分: 无忧币 -2

WIM静态库

回复

使用道具 举报

发表于 2011-4-4 10:46:38 | 显示全部楼层
本人虽然在这个主题下一直不发言,几天来一直关注这个主题。

有关这个native版的mini pecmd,似乎走进了一个误区,定位不准确合理,
native版mini pecmd开始的目的是将内核很得更小,启动更快,这个目的
是不错的,前面不少讨论是CAB的解压和WIM的挂载,就是在bootexecute
通过这个native程序解压CAB或挂载WIM,将一级内核扩展成二级、三级内核,
进而启动winlogon=>pecmd=>explorer,其实这样的功能作用不大,试问
为了启动到explorer,用native工具将文件解压进内核或将WIM挂进内核,这样
启动时间会少么?不会少;内存要求会降么?也不会降;发布的WinPE体积会小么?
同样不会小,因为WinPE内核本来就可以是压缩文件(CAB格式或WIM格式)。
好处本人只想到一点,就是可以根据native.cfg来配置内核。

所以这个native版的mini pecmd的功能和定位应该是WinPE启动到bootexecute项实行
完全方式的系统备份和系统恢复,其它的都不要管,包括系统修复,因为native程序用于
系统修复比较困难,如系统中毒,注册表或BCD出问题,在bootexecute项用native程序
修复文件操作性很差。

如果是将功能定位于仅仅是系统备份和系统恢复,不用理会native.exe后面的是否能启动下去,
就是不管native.exe能否将一级内核扩展成二级内核,只管一个稳定的、内核固定的native PE,
那么完善这个native版的mini pecmd难度就会降低,这样更可以打造一个更具自己新特色的
"体积小、启动快的系统备份和系统恢复"工具。所以这个native程序应更多注意:
1、将某个分区打包成一个文件(CAB或WIM),就是系统备份;
2、将一个压缩包(CAB或WIM)恢复到某个分区,就是系统恢复;
如果处理得好,这样的native程序有可能可以安装到正常硬盘系统的bootexecute项,native程序
启动时给用户3、5秒的选择,在bootexecute处实施备份或恢复当前系统。

如果能在bootexecute项通过native程序备份、恢复当前系统,那么比起主流的通过BOOT.INI或BCD
启动GULDR启动的Ghost系统备份恢复工具来说有两大特色:
1、可以准确确定要备份或恢复的分区,减少使用Ghost恢复系统时错选分区造成资料丢失;
2、可以得到更多更准确的硬盘驱动,包括UBS磁盘驱动。

以上纯属本人观点,如认为不正确,就当本人没说过。

[ 本帖最后由 lxl1638 于 2011-4-4 11:00 编辑 ]

点评

同意这个观点,snapshot就有NATIVE子程序  发表于 2022-2-1 15:11
回复

使用道具 举报

发表于 2011-4-4 11:02:58 | 显示全部楼层

回复 #141 lxl1638 的帖子

打包成CAB可以考虑在NATIVE模式做,但是速度太慢。
WIM打包功能全部由WIMGAPI.DLL完成,要移植到NATIVE工作量太大,而且速度会特别慢。
NATIVESHELL目前的功能是执行一些简单的SHELL命令,可以删除一些顽固病毒、木马等。

目前这个项目目前还处于基本功能完善阶段,连具备哪些功能都说不确定,过早断言能干什么没有什么作用。

源代码的组织,建议把比较独立功能做成静态库放到 lib 下面,这样核心功能比较突出,容易维护,容易进行分工合作,定位问题速度快。
静态库需要改成 TARGETTYPE=LIBRARY 。

我现在分配内存用的是: NtAllocateVirtualMemory ,不知道有没有问题。

[ 本帖最后由 liulaotou2 于 2011-4-4 11:09 编辑 ]
回复

使用道具 举报

发表于 2011-4-4 11:12:51 | 显示全部楼层
原帖由 liulaotou2 于 2011-4-4 11:02 发表
打包成CAB可以考虑在NATIVE模式做,但是速度太慢。
WIM打包功能全部由WIMGAPI.DLL完成,要移植到NATIVE工作量太大,而且速度会特别慢。
NATIVESHELL目前的功能是执行一些简单的SHELL命令,可以删除一些顽固病 ...


好象7Z工具不需用WIMGAPI.DLL(即WimMount组件驱动)也可以解压WIM,不知有没有这方面源码。
回复

使用道具 举报

 楼主| 发表于 2011-4-4 11:38:55 | 显示全部楼层
原帖由 lxl1638 于 2011-4-4 11:12 发表


好象7Z工具不需用WIMGAPI.DLL(即WimMount组件驱动)也可以解压WIM,不知有没有这方面源码。

7z确实有这方面的代码...不过没有C版本的...有C++版本的...对C++不熟悉...无法移植...可能的话把那些代码转成C库调用也不错..
而且这些代码支持的压缩格式很强大..wim,cab,7z,rar,zip通吃

[ 本帖最后由 2011足迹 于 2011-4-4 11:42 编辑 ]
回复

使用道具 举报

发表于 2011-4-4 11:53:02 | 显示全部楼层
原帖由 lxl1638 于 2011-4-4 10:46 发表
本人虽然在这个主题下一直不发言,几天来一直关注这个主题。

有关这个native版的mini pecmd,似乎走进了一个误区,定位不准确合理,
native版mini pecmd开始的目的是将内核很得更小,启动更快,这个目的
是不错的,前面不少讨论是CAB的解压和WIM的挂载,就是在bootexecute
通过这个native程序解压CAB或挂载WIM,将一级内核扩展成二级、三级内核,
进而启动winlogon=>pecmd=>explorer,其实这样的功能作用不大,试问
为了启动到explorer,用native工具将文件解压进内核或将WIM挂进内核,这样
启动时间会少么?不会少;内存要求会降么?也不会降;发布的WinPE体积会小么?
同样不会小,因为WinPE内核本来就可以是压缩文件(CAB格式或WIM格式)。
好处本人只想到一点,就是可以根据native.cfg来配置内核。


我说一下我的观点.

1.启动时间减少是肯定的.特别是U盘,本来需要加载30MB才能启动,现在只要加载5MB左右就可以了.
2.内存要求会不会降,那不一定.还得看内核的结构.
3.发布的WINPE体积不会小,那是自然的.东西本来就那么多,也没有办法少.
回复

使用道具 举报

 楼主| 发表于 2011-4-4 11:53:18 | 显示全部楼层
原帖由 lxl1638 于 2011-4-4 10:46 发表
本人虽然在这个主题下一直不发言,几天来一直关注这个主题。

有关这个native版的mini pecmd,似乎走进了一个误区,定位不准确合理,
native版mini pecmd开始的目的是将内核很得更小,启动更快,这个目的
是 ...

native现在还算是概念版把...只是发现在这个地方有事可做..
至于你提出的几个问题..
首先..可以解决usb2.0驱动的问题..如果主板不支持usb2.0驱动那么可以在usb2.0驱动加载前加载更小的一级内核..2.0加载之后加载二级内核..
另外..wim直接挂载二级内核应该可以提高不少速度..毕竟不需要内存自解压了..也可以节省一些内存..据说内存自解压要消耗双倍内存
现在cab解压速度还是个问题..相信可以解决..主要是内存使用和多线程支持..现在是用一块数据读一块数据..以后可以考虑把文件读入到内存中...再配合多线程和多核支持..速度应该可以提高...不过现在pe1.5没有发现速度影响有太明显..
回复

使用道具 举报

发表于 2011-4-4 11:59:14 | 显示全部楼层
原帖由 chenall 于 2011-4-4 11:53 发表


我说一下我的观点.

1.启动时间减少是肯定的.特别是U盘,本来需要加载30MB才能启动,现在只要加载5MB左右就可以了.
2.内存要求会不会降,那不一定.还得看内核的结构.
3.发布的WINPE体积不会小,那是自然的. ...

5MB至多只能启动到native,真正启动到WinLogon或资源管理器的时间不会少,因为native后要启动资源管理器
还有解压文件过程,没有将5M以外的文件解压进去如何启动后面的进程。
回复

使用道具 举报

发表于 2011-4-4 12:00:17 | 显示全部楼层
原帖由 2011足迹 于 2011-4-4 11:38 发表

7z确实有这方面的代码...不过没有C版本的...有C++版本的...对C++不熟悉...无法移植...可能的话把那些代码转成C库调用也不错..
而且这些代码支持的压缩格式很强大..wim,cab,7z,rar,zip通吃

的确,7Z在这方面是非常强大,呵呵~~

能套用过来的话,解压能力将会巨大提升,呵呵~~
回复

使用道具 举报

发表于 2011-4-4 12:03:14 | 显示全部楼层
原帖由 lxl1638 于 2011-4-4 11:59 发表

5MB至多只能启动到native,真正启动到WinLogon或资源管理器的时间不会少,因为native后要启动资源管理器
还有解压文件过程,没有将5M以外的文件解压进去如何启动后面的进程。


使用WIM挂载就不需要解压啦.
回复

使用道具 举报

 楼主| 发表于 2011-4-4 12:04:30 | 显示全部楼层
原帖由 liulaotou2 于 2011-4-4 11:02 发表
打包成CAB可以考虑在NATIVE模式做,但是速度太慢。
WIM打包功能全部由WIMGAPI.DLL完成,要移植到NATIVE工作量太大,而且速度会特别慢。
NATIVESHELL目前的功能是执行一些简单的SHELL命令,可以删除一些顽固病 ...

关于代码管理..这个建议不错..
内存分配native中都是使用的RtlAllocateHeap..由于没有设置虚拟内存NtAllocateVirtualMemory似乎不会有什么特别
回复

使用道具 举报

发表于 2011-4-4 12:04:33 | 显示全部楼层
原帖由 lxl1638 于 2011-4-4 10:46 发表
本人虽然在这个主题下一直不发言,几天来一直关注这个主题。

有关这个native版的mini pecmd,似乎走进了一个误区,定位不准确合理,
native版mini pecmd开始的目的是将内核很得更小,启动更快,这个目的
是 ...

lxl1638大说用native作GHOST来备份恢复,错区我想只有在自动模式下才会有吧,如果手动的话,应该不存在错区吧

印象中,MS原生的PE3.x 好像没区问题吧?(有记错了请告知吧)

如果拿native作ghost备份恢复,那不如用DOS版或者Linux版更直接吧?

[ 本帖最后由 andos 于 2011-4-4 12:11 编辑 ]
回复

使用道具 举报

 楼主| 发表于 2011-4-4 12:13:37 | 显示全部楼层
原帖由 friend8179 于 2011-4-4 12:08 发表
代码很成功,已经能够成功挂载了

代码完善一下..打个补丁吧...
我就不做重复劳动了..
回复

使用道具 举报

 楼主| 发表于 2011-4-4 12:19:00 | 显示全部楼层
原帖由 andos 于 2011-4-4 12:04 发表

lxl1638大说用native作GHOST来备份恢复,错区我想只有在自动模式下才会有吧,如果手动的话,应该不存在错区吧

印象中,MS原生的PE3.x 好像没区问题吧?(有记错了请告知吧)

如果拿native作ghost备份恢复, ...

ghost方面native只有一个优势...就是磁盘驱动易得..不过要启动到支持ghost的win32模式需要加载的文件应该在8M(pe1.5)左右
回复

使用道具 举报

发表于 2011-4-4 13:32:07 | 显示全部楼层
使用FRE模式编译失败,只能使用CHK模式.

暂时帮不上什么忙,附上一个我修改的build批处理脚本.

Batchfile语言: [A href="http://fayaa.com/code/view//]临时自用代码[/A]
@echo off
cd /d "%~dp0"
::定位WINDDK目录.
if "%DDKDIR%"=="" for %%A in (C D E F) do if exist %%A:\WinDDK\7600.16385.1\ set DDKDIR=%%A:\WinDDK\7600.16385.1\
::设置源码目录
set source=%~dp0
::如果有存在SUBST命令,则使用SUBST虚拟一个B:
::因为如果源码目录存放的路径比较长或带空格时可能会编译失败.
subst && set subst=b: && subst /d b: & cls
if defined subst (subst %subst% . && set source=b:)
::调用编译模块,编译不同的版本.
call :build chk x86 wxp
call :build fre x86 wxp
::取消subst映射
if defined subst subst /d %subst%
pause
goto :eof

:build
setlocal
call %DDKDIR%bin\setenv.bat %DDKDIR% %*
IF NOT DEFINED MINWIN_SDK_LIB_PATH SET MINWIN_SDK_LIB_PATH=%SDK_LIB_PATH%
cd /d "%source%"
if not exist obj%BUILD_ALT_DIR% mkdir obj%BUILD_ALT_DIR%
build.exe /g /w /M 2 /c /F /y /jpath obj%BUILD_ALT_DIR%


回复

使用道具 举报

发表于 2011-4-4 13:37:22 | 显示全部楼层
另外好像Drive SnapShot 可以在native模式下运行,有没有人试一下...
回复

使用道具 举报

发表于 2011-4-4 13:41:45 | 显示全部楼层
原帖由 chenall 于 2011-4-4 13:37 发表
另外好像Drive SnapShot 可以在native模式下运行,有没有人试一下...

是可以的,
但是它的native 好像要配合注册表,而且好像只支持还原动作的似
它的native程序叫snapnative.exe

相关讨论 : http://bbs.wuyou.net/forum.php?mod=viewthread&tid=183485

[ 本帖最后由 andos 于 2011-4-4 13:44 编辑 ]
回复

使用道具 举报

 楼主| 发表于 2011-4-4 13:58:16 | 显示全部楼层
今天用3790版的ddk编译结果失败...缺少头文件...不知道是我下载的是精简版还是本来就没有..
回复

使用道具 举报

发表于 2011-4-4 14:02:16 | 显示全部楼层
发一个 删除某目录和子目录下所以文件批处理,P.S.批处高手可以无视

@echo off
for /f "delims=" %%a in ('dir /s /b "路径"') do (
del /q /f "%%a"
)
pause


红色的"路径"就是你要删除的那个目录和其子目录下的所以文件的路径

这是为了方便大家删文件保留目录用的而已,由其是在选用CAB时
当然希望的是日后可以直接支持,不用预留空目录
我想如果支持WIM的话,解WIM或者挂WIM就应就不用留空目录吧?

[ 本帖最后由 andos 于 2011-4-4 14:04 编辑 ]
回复

使用道具 举报

 楼主| 发表于 2011-4-4 14:05:16 | 显示全部楼层
原帖由 andos 于 2011-4-4 13:41 发表

是可以的,
但是它的native 好像要配合注册表,而且好像只支持还原动作的似
它的native程序叫snapnative.exe

相关讨论 : http://bbs.wuyou.net/forum.php?mod=viewthread&tid=183485

snapnative.exe能在bootexecute中运行也可以被native执行..看来native还需要提供修改注册表的命令...这样就可以运行它的
回复

使用道具 举报

 楼主| 发表于 2011-4-4 14:06:44 | 显示全部楼层
原帖由 andos 于 2011-4-4 14:02 发表
发一个 删除某目录和子目录下所以文件批处理,P.S.批处高手可以无视



红色的"路径"就是你要删除的那个目录和其子目录下的所以文件的路径

这是为了方便大家删文件保留目录用的而已,由其是在选用CAB时
...

最新版的native应该支持自动创建目录了
回复

使用道具 举报

发表于 2011-4-4 14:08:07 | 显示全部楼层
我比较同意老九的观点,用于系统恢复、通用还原。
是否还有一个计划使其用于故障恢复台?

PM这样的分区工具、江民杀软的BootScan都是利用native的。
回复

使用道具 举报

发表于 2011-4-4 14:13:32 | 显示全部楼层
原帖由 2011足迹 于 2011-4-4 14:06 发表

最新版的native应该支持自动创建目录了


你是说native_2011-4-1 19:57 版吗?
如果是的话,没预留空目录会出现解压错误吧
回复

使用道具 举报

 楼主| 发表于 2011-4-4 14:22:40 | 显示全部楼层
原帖由 andos 于 2011-4-4 14:13 发表


你是说native_2011-4-1 19:57 版吗?
如果是的话,没预留空目录会出现解压错误吧

是那个版本...在演示pe中就没有预留孔目录..也不会提示解压错误...最后所有文件解压成功...
有一点要提示...命令中路径最后的\要去掉...否则可能会找不到路径...
在处理路径的逻辑上比较简单..没有考虑\\这种情况...native api也不认这种路径
以后版本中修复吧..
回复

使用道具 举报

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

本版积分规则

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

闽公网安备 35020302032614号

GMT+8, 2024-3-28 21:05

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

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