中国DOS联盟

The SHSUCDX in the boot disk I made is indeed compressed.

P.S.: Roy's signature is getting more and more....

The following is a quote fromWengieron 2003-7-9 8:53:45:
P.S.: Roy's signature is getting more and more.... yeah.

Hehe~~Thanks for the compliment~~

Is this thing stable? Is there any problem?

The following is a quote from yiyesong on 2003-7-8 11:41:44:
I need the complete SHSUCDX file package (including the original code). WENGIER, please upload it.

Uploaded Open the attachment

Thanks a lot, ROY. It's really a timely help. I've been waiting for a whole day.

After seeing ROY's signature, I can't help but reply~~~ :)

The following is a quote from yiyesong on 2003-7-9 14:14:26:
Thank you so much, ROY, it's like a lifeline in the snow. I've been waiting all day.

You're welcome

After verification, when SHSUCDX20a is used with the LH command, UMB confusion will occur. If SMRTDRV, DOSKEY, CTMOUSE, DOSLFN, etc. are loaded after it, the system will crash. If loaded before SHSUCDX, there will be no crash, and reloading these programs later will also not cause a crash. So everyone should not use the LH command, just load it directly, that is, directly SHSUCDX.exe /D:CD001. In fact, it will automatically reside in UMB, and it really only occupies 6.5K memory as it says, not the zero memory occupancy as WENGIER said. Using it like this has good compatibility, and everything is OK. The biggest improvement of 2.0a compared to 1.4b is not only less memory occupancy but also support for long filenames in ISO.

The following is a quote from lydong on 2003-7-9 3:03:37:

The following is a quote from yiyesong on 2003-7-9 1:13:00:
ROY hasn't come all day today, so I had to use the one from the boot disk uploaded by WENGIER. I don't know if WENGIER compressed it. The compatibility is very poor, not as good as SHSUCDX14B.

Yeah, after I changed this, it crashed before it finished booting, but it was fine with the original one.

It is estimated that the compatibility problem is not caused by compression, but by the program itself.

The program has no major problems. Instead, SHSUCDX will automatically reside in UMB. So if you use LH again, it's redundant and will cause UMB confusion. I've tried it, and without LH, the compatibility is very good.

The following is a quote from yiyesong on 2003-7-9 20:00:59:
There are no major problems with the program. Instead, SHSUCDX will automatically reside in UMB, so if you use LH again, it is redundant and will cause UMB confusion. I have tried it, and it is very compatible without LH.

Same as XMSDSK.. Don't use LH to load that aPack-compressed XMSDSK..

The same phenomenon occurs when SHSUCDX is not compressed.

After seeing ROY's signature, I can't help but reply!

I'm scared to death!
So I also need to reply!

The following is a quote from yiyesong on 2003-7-9 19:22:26:
The biggest improvement of 2.0a compared with 1.4b, in addition to less memory usage, also supports the long filenames of ISO.

In fact, SHSUCDX 2.0 still does not support the long filenames of ISO. Even if DOSLFN is loaded in real time, it is useless. It's just that compared with 1.4b, it adopts an improved method to truncate the long filenames of ISO into 8.3 short filenames.