|
Wengier
系统支持
“新DOS时代”站长
积分 27736
发帖 10521
注册 2002-10-9
状态 离线
|
『楼 主』:
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 |
|
|
windrv
中级用户
积分 385
发帖 118
注册 2003-11-11
状态 离线
|
『第
2 楼』:
To Wengier - WINME IO.SYS
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
状态 离线
|
|
|
2003-12-24 00:00 |
|
|
Wengier
系统支持
“新DOS时代”站长
积分 27736
发帖 10521
注册 2002-10-9
状态 离线
|
『第
4 楼』:
那个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 |
|
|
windrv
中级用户
积分 385
发帖 118
注册 2003-11-11
状态 离线
|
『第
5 楼』:
| Quote: | 以下是引用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 楼』:
一些有關DblSpace driver的tech. data
--------d-2F4A12CX4D52-----------------------
INT 2F - Microsoft Realtime Compression Interface (MRCI) - RAM-BASED SERVER
AX = 4A12h
CX = 4D52h ("MR"
DX = 4349h ("CI"
Return: CX = 4943h ("IC" if installed
DX = 524Dh ("RM" if installed
ES 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"
DX = 4349h ("CI"
Return: CX = 4943h ("IC" if installed
DX = 524Dh ("RM" if installed
ESI -> 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 |
|
