中国DOS联盟

Regarding the embedded LOGO in MS-DOS 7.x, I just found the following information online:

The cover of Windows 95 does not have a bitmap file in an independent file form, which is different from the processing of LOGOS.SYS by WIN.COM and the processing of LOGOW.SYS by USER.EXE. The author discovered during the analysis of the boot file IO.SYS that the startup cover logo of Windows 95 is embedded in the boot file IO.SYS and compressed by DBLSPACE, with an image data area length of 64KB. In the version of Windows 95 analyzed by the author, the image data occupies sectors 217-344 of IO.SYS (file length 223748B), and there are multiple "DS" identifiers inside the data, which are signs of DBLSPACE compressed files. Since DBLSPACE is a segmented checksum compressed file, even a change of one byte in this area will cause a large-scale damage to the image. In the above IO.SYS, the part of the image display execution code starts at the place marked with "DBLSBIN$\LOGO.SYS" and occupies sectors 110-112. Because the compressed file of DBLSPACE is very complex and segmented checked, we cannot customize the startup cover like modifying the combined file or recompiling part of the code of WIN.COM for Windows 3.1, but we can blank the display by setting Logo=0 in MSDOS.SYS. The settings of the configuration file MSDOS.SYS are already available in relevant documents, and Appendix 2 of this article briefly describes the configuration setting options.

In fact, the startup cover can also be customized. The author found during the analysis of IO.SYS that before IO.SYS displays the embedded cover internally, it tries to open a file named LOGO.SYS in the boot directory (using the DOS function call INT 21H, AH=3DH sub-function). If the opening fails (this file does not exist), it switches to display the embedded cover internally (when the opening fails in WIN.COM and USER.EXE, it does not display the graphic but replaces it with text to display relevant information). If the opening is successful, it does a file format check, and the required format is more stringent than the check conditions of WIN.COM for LOGOS.SYS.

The code for IO.SYS to check LOGO.SYS is as follows:

debug io.sys
-u de0e
12B9:DE0E 813C424D CMP WORD PTR ,4D42
12B9:DE12 0F DB 0F
12B9:DE13 854801 TEST CX,
12B9:DE16 83C60E ADD SI,+0E
-u de19
12B9:DE19 833C28 CMP WORD PTR ,+28
-u de20
12B9:DE20 837C0C01 CMP WORD PTR ,+01
-u de28
12B9:DE28 837C0E08 CMP WORD PTR ,+08
-u de30
12B9:DE30 817C044001CMP WORD PTR ,0140
-u de39
12B9:DE39 817C089001CMP WORD PTR ,0190
-u de42
12B9:DE42 837C1000 CMP WORD PTR ,+00

From the above code, we can immediately see that the opened file is a non-compressed bitmap file with a size of 320×400, 1 plane, and 256 colors. Therefore, a 256-color non-compressed bitmap file with a size of 320 pixels × 400 pixels can be formed using tools like Paintbrush, named LOGO.SYS, and placed in the boot directory. The required format of LOGO.SYS happens to be consistent with the formats of LOGOS.SYS and LOGOW.SYS. As a verification, renaming LOGOS.SYS or LOGOW.SYS to LOGO.SYS and placing it in the boot directory is fully feasible. If there is a file named LOGO.SYS in the boot directory but it does not pass all the above checks, it will be refused to be displayed and the embedded logo cover will not be displayed either.

IV. Removing the format check for LOGO.SYS and forming a dither-colored logo cover

The external cover image displayed by the above method is static, and there is a scrolling color bar below the image in IO.SYS. The method above can make the image colors change dithered. If the LOGO.SYS in the boot directory is removed, the embedded image in IO.SYS can also achieve "clouds flowing" over the entire picture, with strong movement. The dither coloring of the bitmap is processed by IO.SYS, and the relevant processing flags are embedded in the above judgment statement for LOGO.SYS. Therefore, modifying the relevant statements can be done. The method is: use PCTOOLS or other tools (DEBUG, etc.) to find the parts underlined below, and rewrite them all to the hexadecimal machine code 90 (nop, an empty instruction that does nothing). There are 60 bytes between the beginning and the end, and some code is not listed in the above disassembly.

debug io.sys
-d de00
12B9:DE00 00 93 BA 02 00 E8 D6 02 -0F 82 52 01 8B F2 81 3C ..........R....
12B9:DE10 42 4D 0F 85 48 01 83 C6 -0E 83 3C 28 0F 85 3E 01 BM..H.....
12B9:DE20 83 7C 0C 01 0F 85 36 01 -83 7C 0E 08 0F 85 2E 01 .|....6..|.....
12B9:DE30 81 7C 04 40 01 0F 85 25 -01 81 7C 08 90 01 0F 85 .|.@...%..|....
12B9:DE40 1C 01 83 7C 10 00 0F 85 -14 01 8B 44 24 1E 2E 8E ...|.......D$..
12B9:DE50 1E 3E 0F A2 D8 02 F6 D8 -04 FF A2 D9 02 84 E4 74 .>.............
12B9:DE60 06 A3 DA 02 A3 DC 02 1F -2E C6 06 F2 8E 00 16 07 ...............
12B9:DE70 83 EC 26 8B FC BD 5F 03 -E8 45 02 B9 00 80 E8 E9 ..&..._..E.....

After making the above changes to IO.SYS, any bitmap can be displayed. But since the display is adjusted according to the system display driver and the screen, it is better to keep the original settings in terms of scale. If changes are to be made, testing should be done first, and the result may be distorted, but it does not affect the display and operation. After the above changes, the embedded cover can dither and change colors when there is no external LOGO.SYS. If LOGOS.SYS or LOGOW.SYS is renamed to LOGO.SYS and placed in the boot directory, it can replace the internal cover and have changing colors. However, if these two bitmaps are edited or a new file is formed using Paintbrush, it generally cannot change colors, because the actual colors used in the file formed by Paintbrush are very few, and most of the bitmap color tables are empty. To form a new dither-colored logo, the following should be done:
1. Form a common 256-color bitmap using Paintbrush, etc.;
2. Make the formed bitmap have a complete 256-color index table, which can be obtained from the color index table of LOGOW.SYS or LOGOS.SYS, that is, copy the area from offset 36H to 436H of LOGOW.SYS or LOGOS.SYS to the same area of the new file. Note that do not change the first 0-36H bytes of the bitmap. Name the new file LOGO.SYS and place it in the boot directory.

V. Removing the format check for LOGOS.SYS and LOGOW.SYS by WIN.COM and USER.EXE

The method is similar to the above, and details are not described one by one here.

Since the boot file is very important, changes must be made on the copy. Now, DOS7 uses IFSHLP.SYS to handle file names up to 255B, and the storage of this file name is to change the directory entry attribute byte to 0FH, that is, the VFAT file name attribute (0FH) which is system (04) + hidden (02) + read-only (01) + volume label (08) = 0FH. And use multiple directory entry areas to store the long file name continuously. To prevent data loss, DOS7 shields the absolute disk write INT 26H. The EDIT function of PCTOOLS and other tools calls INT 26H to write to the disk. If changes are made on the hard disk, it will cause the system to deadlock and cancel the disk writing. There is no this problem on the floppy disk. Therefore, it is recommended to modify IO.SYS on the system floppy disk.

It is very easy to form the system floppy disk of DOS7. The disk initialized under DOS7 only needs to copy IO.SYS, MSDOS.SYS, and COMMAND.COM to boot Windows 95, because DOS7 has a more sophisticated BOOT boot area. The boot file IO.SYS can be stored discontinuously, does not occupy the starting cluster, and the file name entry is not the first directory entry.

Appendix: Bitmap file structure

Important fields in the bitmap file header involved in this article
Offset Length(Bytes) Identification information
00H 2 424DH i.e. "BM"
0EH 4 Bitmap information header size 28H=40 bytes
12H 4 Bitmap width in pixels 4001H=320 pixels
16H 4 Bitmap height in pixels 9001H=400 pixels
1AH 2 Number of planes of the bitmap target device 1
1CH 2 Bits per pixel of the bitmap array, can take values:
1: monochrome, 4: 16-color, 8: 256-color, 24: 16 million colors
1EH 4 Bitmap compression flag, can take values: 0: uncompressed, 1: run-length compressed 8-bit bitmap, 2: 4-bit compressed bitmap

Therefore, the bitmap LOGO.SYS read by IO.SYS in this article is a non-compressed, 1-plane, 256-color, 320-pixel wide, 400-pixel high bitmap.

I just successfully replaced the embedded startup LOGO in Win95 with the Win98 startup LOGO from IO.SYS of MS-DOS 7.10. Both booting from a floppy disk and a hard disk are normal, and the Win95 startup LOGO is displayed when MS-DOS 7.10 boots.

Therefore, I think that as long as the BMP format LOGO we want is compressed with DBLSPACE and then embedded into IO.SYS, it should work. However, DBLSPACE is very cumbersome to use, and I don't have the conditions to implement it. What does Roy think? Can we practice it?

Sorry, I don't know how to use dblspace.

If I had a useless hard disk, I could use DBLSPACE for testing.

Who here knows how to use DBLSPACE? Can someone help?

Dictionary Encoding

There are many occasions where the statistical characteristics of the data to be encoded are not known at the beginning, and it may not be allowed for you to know their statistical characteristics in advance. Therefore, people have proposed many data compression methods, trying to compress and encode these data, and to obtain the maximum compression ratio as much as possible in the actual encoding process. These technologies are collectively referred to as universal encoding technologies. Dictionary Encoding technology belongs to this category, and this technology belongs to lossless compression technology.

4.4.1 Idea of Dictionary Encoding
The basis of dictionary encoding is that the data itself contains the characteristic of repeated codes. For example, text files and raster images have this characteristic. There are many types of dictionary encoding methods, which can be roughly classified into two categories.
The idea of the first type of dictionary method is to attempt to find whether the character sequence being compressed has appeared in the previously input data, and then use the already appeared string to replace the repeated part. The output of this method is only a "pointer" pointing to the string that appeared earlier. The encoding concept of this type is shown in Figure 4-06.

Figure 4-06 Coding Concept of the First Type of Dictionary Method
The "dictionary" referred to here means using the previously processed data to represent the repeated parts encountered in the encoding process. All algorithms in this type of encoding are based on the LZ77 algorithm developed and published by Abraham Lempel and Jakob Ziv in 1977. For example, the LZSS algorithm improved by Storer and Szymanski in 1982 belongs to this situation.
The idea of the second type of algorithm is to attempt to create a "dictionary of the phrases" from the input data. This phrase does not necessarily have specific meanings like "rigorous, diligent, practical, innovative" and "national peace and people's happiness is the foundation for sitting firmly in the presidential seat", but it can be any combination of characters. When encountering a "phrase" that has already appeared in the dictionary during the process of encoding data, the encoder outputs the "index number" of the phrase in the dictionary instead of the phrase itself. The concept of this type is shown in Figure 4-07.

Figure 4-07 Coding Concept of the Second Type of Dictionary Method
J. Ziv and A. Lempel first published an article introducing this encoding method in 1978. On the basis of their research, Terry A. Weltch published an article to improve this encoding algorithm in 1984. Therefore, this encoding method is called LZW (Lempel-Ziv Walch) compression encoding, and this algorithm was first applied in high-speed hard disk controllers.

4.4.2 LZ77 Algorithm
To better illustrate the principle of the LZ77 algorithm, first introduce several terms used in the algorithm:
Input stream: The character sequence to be compressed.
Character: The basic unit in the input stream.
Coding position: The current character position in the input stream to be encoded, referring to the starting character in the lookahead buffer.
Lookahead buffer: The memory that stores the character sequence from the coding position to the end of the input stream.
Window: Refers to a window containing W characters, and the characters are counted backward from the coding position, that is, the number of characters processed last.
Pointer: A pointer pointing to the matching string in the window and containing the length.
The core of the LZ77 encoding algorithm is to find the longest matching string starting from the lookahead buffer. The specific execution steps of the encoding algorithm are as follows:
Set the coding position to the starting position of the input stream.
Find the longest matching string in the window.
Output in the format of "(Pointer, Length) Characters", where Pointer is the pointer pointing to the matching string in the window, Length represents the length of the matching characters, and Characters is the first unmatched character in the lookahead buffer.
If the lookahead buffer is not empty, move the coding position and the window forward by (Length + 1) characters, and then return to step 2.
The data stream to be encoded is shown in Table 4-09, and the encoding process is shown in Table 4-10. The following explanations are given:
The "Step" column indicates the encoding step.
The "Position" column indicates the coding position, and the first character in the input stream is coding position 1.
The "Matching string" column indicates the longest matching string found in the window.
The "Character" column indicates the first character in the lookahead buffer after matching.
The "Output" column is output in the format of "(Back_chars, Chars_length) Explicit_character". Among them, (Back_chars, Chars_length) is a pointer pointing to the matching string, telling the decoder "go back Back_chars characters in this window and then copy Chars_length characters to the output", and Explicit_character is the real character. For example, the output "(5,2) C" in Table 4-10 tells the decoder to go back 5 characters and then copy 2 characters "AB".

Table 4-09 Data Stream to be Encoded
Position
1
2
3
4
5
6
7
8
9
Character
A
A
B
C
B
B
A
B
C

Table 4-10 Encoding Process
Step
Position
Matching string
Character
Output
1
1
--
A
(0,0) A
2
2
2
A
B
(1,1) B
3
4
--
C
(0,0) C
4
5
B
B
(2,1) B
5
7
A B
C
(5,2) C

4.4.3 LZSS Algorithm
LZ77 solves the problem of no matching string in the window by outputting real characters, but this solution contains redundant information. The redundant information is manifested in two aspects: one is the empty pointer, and the other is that the encoder may output additional characters, which refer to the characters that may be included in the next matching string. The LZSS algorithm solves this problem in a more effective way. Its idea is to output the pointer if the length of the matching string is longer than the length of the pointer itself, otherwise output the real character. Since the output compressed data stream contains the pointer and the character itself, an additional flag bit, that is, the ID bit, is needed to distinguish them.
The specific execution steps of the LZSS encoding algorithm are as follows:
Place the coding position at the starting position of the input stream.
Find the longest matching string in the lookahead buffer with the window
① Pointer := matching string pointer.
② Length := matching string length.
Judge whether the matching string length Length is greater than or equal to the minimum matching string length (Length ≥ MIN_LENGTH).
If "yes": output the pointer, and then move the coding position forward by Length characters.
If "no": output the first character in the lookahead buffer, and then move the coding position forward by one character.
If the lookahead buffer is not empty, return to step 2.
The encoded string is shown in Table 4-11, and the encoding process is shown in Table 4-12. The following explanations are given:
The "Step" column indicates the encoding step.
The "Position" column indicates the coding position, and the first character in the input stream is coding position 1.
The "Matching" column indicates the longest matching string found in the window.
The "Character" column indicates the first character in the lookahead buffer after matching.
The output in the "Output" column is:
① If the length of the matching string itself Length ≥ MIN_LENGTH, output the pointer pointing to the matching string, in the format of (Back_chars, Chars_length). This pointer tells the decoder "go back Back_chars characters in this window and then copy Chars_length characters to the output".
② If the length of the matching string itself Length ≤ MIN_LENGTH, output the real matching string.

Table 4-11 Input Data Stream
Position
1
2
3
4
5
6
7
8
9
10
11
Character
A
A
B
B
C
C
B
B
A
A
B
C

Table 4-12 Encoding Process (MIN_LENGTH = 2)
Step
Position
Matching string
Output
1
1
--
A
2
2
A
A
3
3
--
--
B
4
4
B
B
5
5
--
C
6
6
B B
(3,2)
7
8
A A B
(7,3)
8
11
C
C

Under the same computer environment, the LZSS algorithm can obtain a relatively high compression ratio than LZ77, and the decoding is also simple. This is why this algorithm has become the basis for developing new algorithms. Many later-developed document compression programs use the idea of LZSS. For example, PKZip, ARJ, LHArc, and ZOO, etc. The difference is only in the length of the pointer and the size of the window, etc.
LZSS can also be used in combination with entropy encoding. For example, ARJ is used in combination with Huffman coding, and PKZip is used in combination with Shannon-Fano, and its subsequent versions also use Huffman coding.


4.4.4 LZ78 Algorithm
--------------------------------------------------------------------------------
Before introducing the LZ78 algorithm, first explain several terms and symbols used in the algorithm:
Charstream: The data sequence to be encoded.
Character: The basic data unit in the charstream.
Prefix: The character sequence before a character.
String: Prefix + character.
Code word: The basic data unit in the codestream, representing a string of characters in the dictionary.
Codestream: The sequence composed of code words and characters, which is the output of the encoder.
Dictionary: String table. Each string is assigned a code word according to the index number in the dictionary.
Current prefix (Current prefix): Used in the encoding algorithm, referring to the current prefix being processed, denoted by P.
Current character (Current character): Used in the encoding algorithm, referring to the character after the current prefix, denoted by C.
Current code word (Current code word): Used in the decoding algorithm, referring to the current code word being processed, denoted by W, and String.W refers to the string of the current code word.

1. Encoding Algorithm
The encoding idea of LZ78 is to continuously extract new strings from the charstream, which is commonly understood as new "entries", and then use the "code" that is the code word to represent this "entry". In this way, the encoding of the charstream becomes replacing the charstream with code words to generate a codestream, thereby achieving the purpose of compressing data. At the beginning of encoding, the dictionary is empty and does not contain any strings. In this case, the encoder outputs a special code word (such as "0") representing an empty string and the first character C in the charstream, and adds this character C to the dictionary as a string composed of one character. In the encoding process, if a similar situation occurs, it is handled in the same way. After the dictionary already contains some strings, if "current prefix P + current character C" is already in the dictionary, the prefix is expanded with the character C, and this expansion operation is repeated until a string that is not in the dictionary is obtained. At this time, the code word corresponding to the current prefix P and the character C are output, and P + C is added to the dictionary as a prefix, and then the next prefix in the charstream is processed.
The output of the LZ78 encoder is a code word-character (W, C) pair. Each time a pair is output to the codestream, the string corresponding to the code word W is expanded with the character C to generate a new string, which is then added to the dictionary. The specific algorithm of LZ78 encoding is as follows:
Step 1: At the beginning, the dictionary and the current prefix P are both empty.
Step 2: Current character C := next character in the charstream.
Step 3: Judge whether P + C is in the dictionary:
(1) If "yes": expand P with C, let P := P + C;
(2) If "no":
① Output the code word corresponding to the current prefix P and the current character C;
② Add the string P + C to the dictionary.
③ Let P := empty value.
(3) Judge whether there are still characters in the charstream to be encoded
① If "yes": return to step 2.
② If "no": if the current prefix P is not empty, output the code word corresponding to the current prefix P, and then end the encoding.

2. Decoding Algorithm
At the beginning of decoding, the decoding dictionary is empty, and it will be reconstructed from the codestream during the decoding process. Whenever a code word-character (W, C) pair is read from the codestream, the code word refers to the string already in the dictionary, then the string of the current code word string.W and the character C are output to the charstream, and the current string (string.W + C) is added to the dictionary. After decoding is completed, the reconstructed dictionary is exactly the same as the dictionary generated during encoding. The specific algorithm of LZ78 decoding is as follows:
Step 1: At the beginning, the dictionary is empty.
Step 2: Current code word W := next code word in the codestream.
Step 3: Current character C := the character following the code word.
Step 4: Output the string of the current code word (string.W) to the charstream, and then output the character C.
Step 5: Add string.W + C to the dictionary.
Step 6: Judge whether there are still code words in the codestream to be decoded
(1) If "yes", return to step 2.
(2) If "no", end.
The encoded string is shown in Table 4-13, and the encoding process is shown in Table 4-14. The following explanations are given:
The "Step" column indicates the encoding step.
The "Position" column indicates the current position in the input data.
The "Dictionary" column indicates the string added to the dictionary, and the index of the string is equal to the "Step" number.
The "Output" column is output in the form of (current code word W, current character C) simplified to (W, C).

Table 4-13 Encoded String
Position
1
2
3
4
5
6
7
8
9
Character
A
B
B
C
B
B
C
A
B
A

Table 4-14 Encoding Process
Step
Position
Dictionary
Output
1
1
A
(0,A)
2
2
B
(0,B)
3
3
B C
(2,C)
4
4
5
B C A
(3,A)
5
8
B A
(2,A)

Compared with LZ77, the biggest advantage of LZ78 is that the number of string comparisons is reduced in each encoding step, and the compression ratio is similar to that of LZ77.


4.4.5 LZW Algorithm
The terms used in the LZW algorithm are the same as those used in LZ78, and one more term - prefix root (Root) is added, which is a string composed of a single character. In terms of encoding principle, there are the following differences between LZW and LZ78: ① LZW only outputs the code word representing the string in the dictionary. This means that at the beginning, the dictionary cannot be empty, and it must contain all single characters that may appear in the charstream, that is, the prefix root (Root). ② Since all possible single characters are included in the dictionary in advance, a one-character prefix is used at the beginning of each encoding step. Therefore, the first string searched in the dictionary has two characters. The LZW encoding algorithm and decoding algorithm are introduced as follows.

1. Encoding Algorithm
LZW encoding is completed around a conversion table called a dictionary. This table is used to store the character sequence called the prefix, and a code word, or called a serial number, is assigned to each table item, as shown in Table 4-15. This conversion table actually expands the 8-bit ASCII character set, and the added symbols are used to represent variable-length ASCII strings that appear in text or images. The expanded code can be represented by 9 bits, 10 bits, 11 bits, 12 bits, or even more bits. Welch's paper uses 12 bits. 12 bits can have 4096 different 12-bit codes, which means that the conversion table has 4096 table items, among which 256 table items are used to store defined characters, and the remaining 3840 table items are used to store prefixes.

Table 4-15 Dictionary
Code word
Prefix
1
…
…
193
A
194
B
…
…
255
…
…
…
1305
abcdefxyF01234
…
…

The LZW encoder (software encoder or hardware encoder) completes the conversion between input and output by managing this dictionary. The input of the LZW encoder is a charstream, which can be a string composed of 8-bit ASCII characters, and the output is a codestream represented by n bits (for example, 12 bits). The code word represents a single character or a string composed of multiple characters. The LZW encoder uses a very practical parsing algorithm called the greedy parsing algorithm. In the greedy parsing algorithm, each parsing has to serially check the string from the charstream, and decompose the longest recognized string, that is, the longest prefix that has appeared in the dictionary. Use the known prefix (Prefix) plus the next input character C, that is, the current character (Current character), as the extended character of this prefix to form a new extended string - string: Prefix.C. Whether this new string should be added to the dictionary also depends on whether there is the same string in the dictionary. If yes, then this string becomes the prefix (Prefix), and continue to input new characters. Otherwise, this string is written to the dictionary to generate a new prefix (Prefix) and a code is given.
The specific execution steps of the LZW encoding algorithm are as follows:
Step 1: At the beginning, the dictionary contains all possible roots (Roots), and the current prefix P is empty;
Step 2: Current character (C) := next character in the charstream;
Step 3: Judge whether the string P + C is in the dictionary
(1) If "yes": P := P + C // (expand P with C);
(2) If "no"
① Output the code word representing the current prefix P to the codestream;
② Add the string P + C to the dictionary;
③ Let P := C // (now P only contains one character C);
Step 4: Judge whether there are still code words in the codestream to be decoded
(1) If "yes", return to step 2;
(2) If "no"
① Output the code word representing the current prefix P to the codestream;
② End.
The LZW encoding algorithm can be represented by pseudo-code. At the beginning, it is assumed that the encoding dictionary contains several defined single code words. For example, 256 character code words, which can be represented by pseudo-code as:
--------------------------------------------------------------------
Dictionary ← all n single-character, j = 1, 2, …, n
j ← n+1
Prefix ← read first Character in Charstream
while((C ← next Character)!=NULL)
Begin
If Prefix.C is in Dictionary
Prefix ← Prefix.C
else
Codestream ← cW for Prefix
Dictionary ← Prefix.C
j ← n+1
Prefix ← C
end
Codestream ← cW for Prefix
--------------------------------------------------------------------

2. Decoding Algorithm
The LZW decoding algorithm also uses two other terms: ① Current code word (Current code word): refers to the current code word being processed, denoted by cW, and string.cW refers to the current string; ② Previous code word (Previous code word): refers to the code word prior to the current code word, denoted by pW, and string.pW refers to the previous string.
At the beginning of LZW decoding, the decoding dictionary is the same as the encoding dictionary, and it contains all possible prefix roots (roots). The LZW algorithm remembers the previous code word (pW) during the decoding process. After reading the current code word (cW) from the codestream, the current string string.cW is output, and then the previous string string.pW expanded by the first character of string.cW is added to the dictionary.
The specific execution steps of the LZW decoding algorithm are as follows:
Step 1: At the beginning of decoding, the dictionary contains all possible prefix roots (Roots).
Step 2: cW := the first code word in the codestream.
Step 3: Output the current string string.cW to the codestream.
Step 4: Previous code word pW := current code word cW.
Step 5: Current code word cW := next code word in the codestream.
Step 6: Judge whether the previous string string.pW is in the dictionary
(1) If "yes", then:
① Output the previous string string.pW to the charstream.
② Current prefix P := previous string string.pW.
③ Current character C := the first character of the current string string.cW.
④ Add the string P + C to the dictionary.
(2) If "no", then:
① Current prefix P := previous string string.pW.
② Current character C := the first character of the current string string.cW.
③ Output the string P + C to the charstream, and then add it to the dictionary.
Step 7: Judge whether there are still code words in the codestream to be decoded
(1) If "yes", return to step 4.
(2) If "no", end.
The LZW decoding algorithm can be represented by pseudo-code as follows:
----------------------------------------------------------------
Dictionary ← all n single-character, j = 1, 2, …, n
j ← n+1
cW ← first code from Codestream
Charstream ← Dictionary
pW ← cW
While((cW ← next Code word)!=NULL)
Begin
If cW is in Dictionary
Charstream ← Dictionary
Prefix ← Dictionary
cW ← first Character of Dictionary
Dictionary ← Prefix.cW
j ← n+1
pW ← cW
else
Prefix ← Dictionary
cW ← first Character of Prefix
Charstream ← Prefix.cW
Dictionary ← Prefix.C
pW ← cW
j ← n+1
end
----------------------------------------------------------------

The encoded string is shown in Table 4-16, and the encoding process is shown in Table 4-17. The following explanations are given:
The "Step" column indicates the encoding step;
The "Position" column indicates the current position in the input data;
The "Dictionary" column indicates the string added to the dictionary, and its index is in parentheses;
The "Output" column indicates the code word output.
Table 4-16 Encoded String
Position
1
1
2
3
4
5
6
7
8
9
Character
A
B
B
A
B
A
B
A
C

Table 4-17 LZW Encoding Process
Step
Position
Dictionary
Dictionary
Output
　 　 (1)
A
　
　 　 (2)
B
　
　 　 (3)
C
　
1
1
(4)
A B
(1)
2
2
(5)
B B
(2)
3
3
3
(6)
B A
(2)
4
4
(7)
A B A
(4)
5
6
(8)
A B A C
(7)
6
--
--
--
(3)

Table 4-18 explains the decoding process. In each decoding step, the decoder reads a code word, outputs the corresponding string, and adds it to the dictionary. For example, in step 4, the previous code word (2) is stored in the previous code word (pW), the current code word (cW) is (4), the current string string.cW is output ("A B"), the previous string string.pW ("B") is the first character of the current string string.cW ("A"), and the result ("B A") is added to the dictionary, and its index number is (6).

Table 4-18 LZW Decoding Process
Step
Code
Dictionary
Output
　 　 (1)
A
　
　 　 (2)
B
　
　 　 (3)
C
　
1
(1)
--
--
A
2
(2)
(2)
(4)
A B
B
3
(2)
(5)
B B
B
4
(4)
(6)
B A
A B
5
(7)
(7)
A B A
A B A
6
(3)
(8)
A B A C
C

The LZW algorithm is widely adopted, and its speed is faster than that of the LZ77 algorithm because it does not need to perform so many string comparison operations. Further improvements to the LZW algorithm include increasing the variable code word length and deleting old strings in the dictionary. The LZW algorithm after these improvements has been adopted in the GIF image format and the UNIX compression program. The LZW algorithm has obtained a patent, and the owner of the patent is Unisys, a large computer company in the United States. Except for commercial software production companies, the LZW algorithm can be used for free.

The following is a quote from Wengier on 2003-4-19 19:20:05:
If I had a useless hard drive, I could test DBLSPACE.

Try using DBLSPACE in VPC

DBLSPACE can only be used in MS-DOS 6.0 or MS-DOS 6.20, and it won't work with other versions of DOS.

Is it impossible to install DOS 6.22 in VPC?

DOS 6.22 or other versions don't work, I've tried. Only DOS 6.0 or 6.20 can be installed to run DBLSPACE for compression. Where can I find the full version of MS-DOS 6.0 or 6.20?

hunome: The addition of embedded logos can be done, and I have basically achieved it, but it's quite complicated to operate, so it's not very practical. As for displaying different logos when starting different DOS systems, it can be done by modifying the corresponding strings in IO.SYS.

I have an MS Dos 6.0 but don't know how to use DoubleSpace

So far, I already have MS-DOS 6.0, but since the operation of adding the LOGO is very complicated, I'll just forget it and use LOGO.SYS.

I thought it would be relatively easy, but it turns out even wengier can't handle it. Is there any other way to make different DOS systems display different logos when booting?