中国DOS联盟论坛

中国DOS联盟

-- 联合DOS 推动DOS 发展DOS --

联盟域名:www.cn-dos.net  论坛域名:www.cn-dos.net/forum
DOS,代表着自由开放与发展,我们努力起来,学习FreeDOS和Linux的自由开放与GNU精神,共同创造和发展美好的自由与GNU GPL世界吧!

游客:  注册 | 登录 | 命令行 | 搜索 | 上传 | 帮助 »
作者:
标题: To Wengier - WINME IO.SYS 上一主题 | 下一主题
Wengier
系统支持

“新DOS时代”站长


积分 27736
发帖 10521
注册 2002-10-9
状态 离线
『楼 主』:   使用 LLM 解释/回答一下

WinME(DOS8)的IO.SYS是由三部分组成的:

第一部分:引导部分。这部分跟DOS7的IO.SYS基本是一样的,所以没有什么必要进行修改或研究。

第二部分:用DBLSPACE压缩过的部分。

第三部分:DBLSPACE压缩的解压程序。这段程序和DOS7中用于解压内嵌LOGO的解压程序是基本相同的。

所以说,只要有独立的DBLSPACE的解压程序就一切好办了,不过到目前为止我还没有发现这样的程序,所以正在继续研究中。




Wengier - 新DOS时代

欢迎大家来到我的“新DOS时代”网站,里面有各类DOS软件和资料,地址:
http://wendos.mycool.net/

E-Mail & MSN: wengierwu AT hotmail.com (最近比较忙,有事请联系DOSroot和雨露,谢谢!)

2003-12-10 00:00
查看资料  发送邮件  访问主页  发短消息  网志  OICQ (29206679)  编辑帖子  回复  引用回复
windrv
中级用户




积分 385
发帖 118
注册 2003-11-11
状态 离线
『第 2 楼』:  To Wengier - WINME IO.SYS 使用 LLM 解释/回答一下

Hello Wengier,

I have seen your posting on debugging Win95/98 io.sys for replacing start-up logo and found it very informative.

Since you are an expert in this area, I don't know if you could solve a long standing problem for us all about booting WINME into real-DOS mode.

There has been a patch for enabling real-DOS mode for WINME booting from hard-disk. However, no matter whether it is booting from floppy or hard disk, the io.sys of WINME automatically loads up its built-in/embedded himem.sys.

This prevents loading other memory manager as well as some pre-OS programmes. I don't know if this affects Grub for DOS.

So do you have any idea by debugging the WINME io.sys so that a crack or a patch can be found for disabling the automatic loading of himem.sys by WINME io.sys on boot-up?


2003-12-24 00:00
查看资料  发送邮件  访问主页  发短消息  网志   编辑帖子  回复  引用回复
Roy
管理员

專業島民



积分 4869
发帖 1633
注册 2002-12-10
状态 离线
『第 3 楼』:   使用 LLM 解释/回答一下

我們也想做到......可是不得其門而入呢.....
先得把io.sys解密才可以.....




我的網站:http://mw16.2ya.com/ 我的網誌: http://scrappedblog.blogspot.com/
~
我的Winamp正在播放的歌曲:
2003-12-24 00:00
查看资料  发短消息  网志   编辑帖子  回复  引用回复
Wengier
系统支持

“新DOS时代”站长


积分 27736
发帖 10521
注册 2002-10-9
状态 离线
『第 4 楼』:   使用 LLM 解释/回答一下

那个IO内嵌的HIMEM.SYS是比较特别的一个版本,虽然功能不错,但兼容性不见得很好,比如说它和EMM386不兼容。




Wengier - 新DOS时代

欢迎大家来到我的“新DOS时代”网站,里面有各类DOS软件和资料,地址:
http://wendos.mycool.net/

E-Mail & MSN: wengierwu AT hotmail.com (最近比较忙,有事请联系DOSroot和雨露,谢谢!)

2003-12-25 00:00
查看资料  发送邮件  访问主页  发短消息  网志  OICQ (29206679)  编辑帖子  回复  引用回复
windrv
中级用户




积分 385
发帖 118
注册 2003-11-11
状态 离线
『第 5 楼』:   使用 LLM 解释/回答一下

以下是引用Wengier在2003-12-10 22:32:52的发言:
WinME(DOS8)的IO.SYS是由三部分组成的:

第一部分:引导部分。这部分跟DOS7的IO.SYS基本是一样的,所以没有什么必要进行修改或研究。

第二部分:用DBLSPACE压缩过的部分。

第三部分:DBLSPACE压缩的解压程序。这段程序和DOS7中用于解压内嵌LOGO的解压程序是基本相同的。

所以说,只要有独立的DBLSPACE的解压程序就一切好办了,不过到目前为止我还没有发现这样的程序,所以正在继续研究中。


I think in Linux there is some open-source code on dblspace compression/decompression algorithm.


2003-12-29 00:00
查看资料  发送邮件  访问主页  发短消息  网志   编辑帖子  回复  引用回复
roy
管理员

專業島民



积分 4869
发帖 1633
注册 2002-12-10
状态 离线
『第 6 楼』:   使用 LLM 解释/回答一下

一些有關DblSpace driver的tech. data

--------d-2F4A12CX4D52-----------------------
INT 2F - Microsoft Realtime Compression Interface (MRCI) - RAM-BASED SERVER
AX = 4A12h
CX = 4D52h ("MR"<img src="images/smilies/face-wink.png" align="absmiddle" border="0">
DX = 4349h ("CI"<img src="images/smilies/face-wink.png" align="absmiddle" border="0">
Return: CX = 4943h ("IC"<img src="images/smilies/face-wink.png" align="absmiddle" border="0"> if installed
DX = 524Dh ("RM"<img src="images/smilies/face-wink.png" align="absmiddle" border="0"> if installed
ES<img src="images/smilies/face-smile-big.png" align="absmiddle" border="0">I -> MRCINFO structure (see INT 1A/AX=B001h)
Note: this call is functionally identical to INT 1A/AX=B001h, but should be
called first, as the latter call is used for the first, ROM-based
MRCI server, while this call is used for RAM-based servers which
may be partially or entirely replacing a prior server
SeeAlso: INT 1A/AX=B001h

--------d-1AB001CX4D52-----------------------
INT 1A - Microsoft Real-Time Compression Interface (MRCI) - ROM-BASED SERVER
AX = B001h
CX = 4D52h ("MR"<img src="images/smilies/face-wink.png" align="absmiddle" border="0">
DX = 4349h ("CI"<img src="images/smilies/face-wink.png" align="absmiddle" border="0">
Return: CX = 4943h ("IC"<img src="images/smilies/face-wink.png" align="absmiddle" border="0"> if installed
DX = 524Dh ("RM"<img src="images/smilies/face-wink.png" align="absmiddle" border="0"> if installed
ES<img src="images/smilies/face-smile-big.png" align="absmiddle" border="0">I -> MRCINFO structure (see below)
Note: this call is functionally identical to INT 2F/AX=4A12h, which should
be called first, as this call is used for the first, ROM-based
MRCI server, while the other call is used for RAM-based servers
which may be partially or entirely replacing a prior server
SeeAlso: INT 2F/AX=4A12h

Format of MRCINFO structure:
Offset Size Description
00h 4 BYTEs vendor signature
"MSFT" Microsoft
04h WORD server version (high=major)
06h WORD MRCI specification version
08h DWORD address of server entry point
0Ch WORD bit flags: server capabilities (see below)
0Eh WORD bit flags: hardware assisted capabilities (see below)
10h WORD maximum block size supported by server (at least 8192 bytes)

Bitfields for capabilities:
bit 0 standard compress
bit 1 standard decompress
bit 2 update compress
bit 3 MaxCompress
bit 4 reserved
bit 5 incremental decompress
bits 6-14 reserved
bit 15 this structure is in ROM and can't be modified
(server capabilities only)

Call MRCI entry point with:
DS:SI -> MRCREQUEST structure (see below)
CX = type of client (0000h application, 0001h file system)
AX = operation
0001h perform standard compression
0002h perform standard decompression
0004h perform update compression
0008h perform MaxCompress
0020h perform incremental decompression
AX = FFFFh clear flags
BX = bitmask of flags to clear (set bits in BX are flags to clear)
Return: AX = status
0000h successful
0001h invalid function
0002h server busy, try again
0003h destination buffer too small
0004h incompressible data
0005h bad compressed data format
Note: MRCI driver may chain to a previous driver

Format of MRCREQUEST structure:
Offset Size Description
00h DWORD pointer to source buffer
04h WORD size of source buffer (0000h = 64K)
06h WORD (UpdateCompress only)
(call) offset in source buffer of beginning of changed data
(return) offset in destination buffer of beginning of changed
compressed data
08h DWORD pointer to destination buffer
must contain original compressed data for UpdateCompress
0Ch WORD size of destination buffer (0000h = 64K)
any compression: size of buffer for compressed data
standard decompression: number of bytes to be decompressed
incremental decompression: number of byte to decompress now
(return) actual size of resulting data
0Eh WORD client compressed data storage allocation size
10h DWORD incremental decompression state data
set to 00000000h before first incremental decompression call
Notes: the source and destination buffers may not overlap
the source and destination buffer sizes should normally be the same
application should not update the contents of the MRCREQUEST structure
between incremental decompression calls





我的網站:http://mw16.2ya.com/ 我的網誌: http://scrappedblog.blogspot.com/
~
我的Winamp正在播放的歌曲:
2003-12-29 00:00
查看资料  发短消息  网志   编辑帖子  回复  引用回复

请注意:您目前尚未注册或登录,请您注册登录以使用论坛的各项功能,例如发表和回复帖子等。


可打印版本 | 推荐给朋友 | 订阅主题 | 收藏主题



论坛跳转: