OK, since the thread from the old OSBA seems to have got lost, I'll post the progress and team member lists, as well as some information, here.

MS-DOS 6.40 is my custom DOS project, it's based on MS-DOS 6.22, and the goal is basically to achieve a DOS with support for many languages (including difficult-to-code ones, such as Arabic, Chinese (currently Simplified only), Hebrew, Japanese, Korean, etc.), updated MSAV virus signatures list (from the official 1996 MS update), a better editor, corrected COUNTRY.SYS information, and other new features.

Progress list:----------------------------------------------------------------By now, the following is done of MS-DOS 6.40:- Added a 386 check to IO.SYS (i.e. it now simply halts with an error message if you have a processor, worse than 386); Have to re-add, using IBM PC DOS 7.1 kernel now;- Replaced MS-DOS 6.22's IO.SYS with IBM PC DOS 7.1's IBMBIO.COM, renamed to IO.SYS and appropriate strings modified;- Replaced MS-DOS 6.22's MSDOS.SYS with IBM PC DOS 7.1's IBMDOS.COM, renamed to MSDOS.SYS;- Modified the COUNTRY entries in MSDOS.SYS to support types 3 (lowercase table - partially supported by stock MS-DOS 6.2x and later) and 8 (next code page for current country - new to 6.40);- Replaced the standard COMMAND.COM with the COMMAND.COM from IBM DOS 7.1, with appropriate strings modified;- Changed the version numbers (I mean the hard-coded binary ones) of IO.SYS, COMMAND.COM, and MSDOS.SYS to 6.40;- Modified the version numbers in the README.TXT and NETWORKS.TXT files to 6.4;- Changed the stupid "Wrong DBLSPACE.BIN version" message in IO.SYS to a better message, "Compression driver can't be set up. /.../", taken straight out of Windows 95's IO.SYS; Have to redo, using IBM PC DOS 7.1 kernel now, maybe not even doable with this kernel, I need to see;- Made EGA?.CPI files with code pages 775 (Baltic Sea), 862 (Hebrew), and several Arabic code pages (864, 708, 720, etc.), and KEYBRD?.SYS files with the keyboard layout for the Baltic Sea languages;- Prepared 8x16 font files (8x8 and 8x14 not yet) for every SBCS code page supported, as well for the SBCS parts of code pages 932 (Japanese Shift-JIS), 934 (Korean IBM), and 954 (Japanese EUC-JP), as well as the DBCS fonts for the same three code pages;- Made MULTILNG.SYS based on a disassembled version of BILING.SYS from Korean MS-DOS 6.00, with extensions to the API, including the ability to have multiple DBCS font drivers loaded;- Modified JDISP.SYS into ADISP.SYS, a universal DBCS code page display driver, that now supports all DBCS code pages that are going to besupported by MS-DOS 6.40;- Replaced JFONT.SYS with AFONTX.SYS (XMS) and AFONTE.SYS (EMS), that can load SBCS and DBCS fonts from files with a better format that allows you to actually specify what DBCS ranges the font supports rather than them being hardcoded into the font driver (which would require a self-modifying font driver, which isn't good) - this new font driver is my modification of an open-source driver, modified to be able to load fonts for a specified code page (specified as a parameter) based on appropriately named .INI files, and to properly talk to MULTILNG.SYS;- Added to Windows 98 SE's COUNTRY.SYS definitions that are missing from it but are in IBM PC DOS 7.1's COUNTRY.SYS, as well as new definitions for DBCS code pages that weren't there (but still have to add all the other countries and code pages that it's going to support but it's missing);- Modified RECOVER.EXE from MS-DOS 5.00 November 11th, 1991 release (MS-DOS 5.00a), in order to assume 6.40 as its correct version and to state in its strings that it's part of MS-DOS 6, rather than MS-DOS 5;- Added IFSHLP.SYS from Windows 95; - Updated COUNTRY.TXT with information for the new included code pages, keyboard layouts, and country information;- Replaced the old MS-DOS Editor with the version from "MS-DOS 7 beta", that is the original version of the editor which was later used in Windows 9x;- Added the Arabic and Hebrew languague support, using files from Arabic and Hebrew editions of MS-DOS 5.00;- Wrote the SYSCP.SYS device driver to allow changing the System Code Page, which allows running of certain applications included with MS-DOS 7.10 (of Windows 9x);- Wrote a large part of the MSDOSX advanced API (but it's still in progress);- Replaced its version of SMARTDRV.EXE with the newer version from Windows 98 Second Edition installations, and MSD.EXE with the one from Windows 95 RTM.

Things to do remain the following:- Finish the rewrite of Setup from scratch;- Update the information in DOSSETUP.INI to reflect the changes in version 6.40 - this will be easy, since I already wrote a program, which can decompile the binary DOSSETUP.INI file to a text version, and also compile such text files back to binary DOSSETUP.INI files;- Modify both hard-coded (binary) and textual version numbers in all programs to reflect the new version number;- See if mr. Hochstätter's FDREAD can make DOS read Japanese floppy formats (1.22 MB 3.5" and 800 or so kB 3.5") and try to modify it accordingly if it doesn't;- Finish the optional Advanced API module;- Add all the other code pages and fonts still missing, and try to modify ADISP.SYS for allow to a Korean/Chinese-like 640x400 DBCS mode using the standard segment B800h text buffer for compatibility with Korean and Chinese applications;- And some other stuff as well, not yet decided by now, but will be decided in the future.

Deprecated things:- Replaced MS-DOS 6.22's MSBACKUP with the updated version from the unofficial MS-DOS 7.1 (of that Chinese group) (that's the Simplified Chinese MSBACKUP with English overlays, not updated, so useless to replace it with);- Modify the SETUP.EXE file to assume 6.40 as the correct MS-DOS version (found out how to but it's deprecated as I decided to rewrite Setup from scratch).

Legend:- Red: This feature is required, in order that the first Alpha can be released;- Green: This feature is already being worked on;- Blue: Both.----------------------------------------------------------------

Team member list:----------------------------------------------------------------- me.----------------------------------------------------------------

That would be it. Feedback would be more than appreciated, and all announcements and releases regarding this project will be posted in this thread.

Updated 2012-11-28: Edit progress according to the latest, same with the Team member list.

Updated 2014-12-10: Edit progress according to the latest.

Last edited by Battler on Wed Nov 28, 2012 9:51 pm, edited 1 time in total.

OK, I wanted to say, that this project is still active, and that Team members are still needed.
I think sHARD>> can be definitely counted as out of the Team, so this is one Team member left, unfortunately. So, if you think you can help us with anything at all, say it here.

My current MS-DOS 6.30 is pretty generic and scripted, one can roll off the files to match pretty much any version, copyright date etc. For example, i have a MS-DOS 6.22 pretending to be MS-DOS 7.10, MS-DOS 5.00 (same as Windows NT), and MS-DOS 6.40.

It's pretty much the full install, except that we don't modify the help file here (I do have a modded help file for the MS-DOS 7.10, but this is the MS-DOS 7.10.2400 build, not the MS-DOS 6.22 hack.

On noting that PC-DOS 7.0 is pretty much "version free", i decided to apply the same sort of thing to msdos (eg 5.00, 6.xx) and mswin (7.x, 8.x). The result is a script to convert msdos 6.22 into pretty much anything, (eg 5.00, 6.30, 6.40, 7.10), and "de-versioned" copies of all of the relevant msdos, mswin, pcdos files.

1. QBASIC help/edit. I use a version of qbasic with a number of patches applied,

The phatcode read-drive-a hack

The *.TXT to *.* open all hack

The EDIT.HLP to HELP.HLP code.

With the last, and a suitably rebuilt help file it is relatively easy to open help.hlp inside the editor, and cut and past from the help into the current file. see, eg Help in QBASIC.

EDIT.COM becomes QBED.COM here.

FASTHELP (dos5 help system) becomes DOSHELP, to match the help file.

2. FDISK seems to not depend on which version of DOS it comes from (when deversioned), but format.com seems to have problems finding the boot sector if used with a different kind of DOS.

3. The MS-Drivers (mouse, mscdex, himem, emm386, smartdrv, ramdrive, ipfhlp) are version independent in an case, so one could poach the win98 or winme stuff under MS-DOS 5.0 etc. I used these in this way for many years.

I have not looked at the PC-DOS 7.10 mscdex.exe, but i think it may be later than the ms-dos ones.

4. The MSD.EXE 3.01 version roughly corresponds to vers 2.12. Win95 2.13 and Win98 2.14 are later, but i don't know how to reactivate the Operating system button. 3.00 actually has a deactivated registry button. I came across a really early version (infer), which shows the mscdex driver.

5. Version-free copies of msdos, mswin and pcdos have been created. These pretty much run everywhere. I also created a /HELP directory, for all sorts of utilities bundled with DOS, but have no version attached.

So, after a long time, this thread is being revived with updated information. First, the temporary upversion from MS-DOS 6.40 to 6.50 has been reverted - it's now 6.40 again. Secondly, the plans with Setup have changed considerably - from simply modifying the original Setup to recognize 6.40 as correct instead of 6.22, to rewriting it from scratch so I can use better compress (most likely Deflate), and so it can handle the OS's planned improved international support better.As for the international support itself, work on getting the Microsoft version of Japanese support is basically done, all that needs to be done yet is to change the files' hardcoded binary version numbers from 6.20 to 6.40. I've also written a small device driver, called SETJCPS.SYS, that sets the System and default Active Code Pages to 932 (Japanese) so some applications such as Japanese Windows 9x's MS-DOS Editor, correctly think they're under Japanese DOS/V, and thus work. Work on other code pages is being done too, there will be support for languages DOS never previously supported, such as Armenian, Vietnamese or Esperanto, as well as native support for long-forgotten character sets such as the Yugoslavian ASCII-7 one (code page 999).

This is all for now, updates will be posted her as work goes on. If anyone wishes to join the Team, I'll be glad to accept you in, after all, as they say in my country, more heads know more so the more people are in the Team, the more and better we can do.

Looks interesting, could I join? I could help with the Setup (I already have a project for it in VBDOS, but it needs uncompressed files. If you need to work with compressed files, it's simple to change some lines...)

Well I'm recoding Setup in C and x86 ASM, with OpenWatcom. I have the first screen displayed and the file copying mechanism ready (automatically decompresses file if it's compressed). What's taking me time is making an UI that works like that of original MS-DOS Setup. That and translating my DOSSETUP.INI reading code from PowerBasic to C and making a proper parser for it so I can make it read that and copy files accordingly. And the most difficult part will be to write the part that prepares the hard disk main partition and formats it, if there's no partition or the main partition is not formatted. I'd need a tutorial somewhere to do that. I hope MS-DOS has some INT 21h calls for that so I don't need to use hardware calls. Or at least a way to call FDISK in a quiet way (there is /AUTOTEST to that with FORMAT).

Edit: I'm also thinking of adding FAT32 support if it's possible to do so by simply injecting relevant code into IO.SYS. Otherwise, it's no go for that, though maybe using the PC-DOS 7.10 boot files for that, after modifying them accordingly (to say MS-DOS instead of PC-DOS, and to be version 6.40 rather than 7.10) would work.

As for FAT32 support, why not just use the files from MS-DOS 7.1/8.0 in Windows 95 OSR 2.x/98/Me (Millennium Edition)? Certainly, that in itself supports FAT32, and more...

Also, I have several ideas:

1. Reuse the low level VMM kernel from Windows 3.x Enhanced Mode/Windows 9x, by creating a copy of COMMAND.COM (or DOSSHELL.EXE for that matter), renamed to KRNL386.EXE, and WIN386.EXE/VMM32.VXD/whatever renamed to DOS386.EXE. There is quite a load of information regarding this in Andrew Schulman's book, Unauthorized Windows 95, with detailed instructions on how to accomplish this, infact, even if it conflicted with an existing installation of Windows, you could just type EXIT anyway to return to the normal DOS command prompt, and then just load the Windows installation from there.

2. Since DriveSpace in Windows 95 temporarily restarts the system using the basic Windows 3.1 files from Mini-Windows (also used by Windows 95/98/Me Setup), to load a 16-bit compatible version of DriveSpace (and later Disk Defragmenter), you could take the Mini-Windows versions of both, and add them into your project. All you would need, really, is to first install Windows 95 in a virtual machine, then compress the disk with DriveSpace, and then, once the whole thing was finished, copy the files from the host drive to your main system, and then add them into your project from there.

3. With the help of XMSDISK, several months back, I was even able to write a driver (basically, a .BAT file that required XMSDISK as an assistant) to move the Windows 9x operating system into RAM, and then instruct Windows to load it from the RAM drive rather than the actual hard drive, to increase performance. Of course, some data would still be read from the hard drive, and of course, copying the files to the RAM drive meant that it took a bit longer for the system to boot up than usual, but all in all, especially on more modern systems, it could easily save performance in the long run (by the way, I called this utility of mine "CACHEOS").

4. Possibly even have environments (such as a Windows 2.x-based version, a Windows 3.x-based version, and a Windows 9x-based version), where only enough of Windows is present to allow preemptive multitasking of many different DOS programs at once (in different windows), without any of the other portions being present (unless, in the case of a shared installation, the user were to load it at their own request, similar to typing "WIN" at a normal command prompt). Reading the antitrust documents reveals that Microsoft itself even had a similar idea at one point.

As for FAT32 support, why not just use the files from MS-DOS 7.1/8.0 in Windows 95 OSR 2.x/98/Me (Millennium Edition)? Certainly, that in itself supports FAT32, and more...

Because they don't look like DOS. Different structure (no separation of IO.SYS and MSDOS.SYS, Windows-related stuff in that I don't want), different string handling. I want a MS-DOS that looks like MS-DOS, not like Windows 9x's DOS. And if I use appropriately renamed PC-DOS 7.10 files for that, it's certainly going to look closer to what I want.

Quote:

Also, I have several ideas:

1. Reuse the low level VMM kernel from Windows 3.x Enhanced Mode/Windows 9x, by creating a copy of COMMAND.COM (or DOSSHELL.EXE for that matter), renamed to KRNL386.EXE, and WIN386.EXE/VMM32.VXD/whatever renamed to DOS386.EXE. There is quite a load of information regarding this in Andrew Schulman's book, Unauthorized Windows 95, with detailed instructions on how to accomplish this, infact, even if it conflicted with an existing installation of Windows, you could just type EXIT anyway to return to the normal DOS command prompt, and then just load the Windows installation from there.

Why? I want DOS, not DOS/386. Sure I find the DOS/386 idea interesting but I'd make that a separate project.

Quote:

2. Since DriveSpace in Windows 95 temporarily restarts the system using the basic Windows 3.1 files from Mini-Windows (also used by Windows 95/98/Me Setup), to load a 16-bit compatible version of DriveSpace (and later Disk Defragmenter), you could take the Mini-Windows versions of both, and add them into your project. All you would need, really, is to first install Windows 95 in a virtual machine, then compress the disk with DriveSpace, and then, once the whole thing was finished, copy the files from the host drive to your main system, and then add them into your project from there.

Or extract the files from MINI.CAB. But that's useless, as those files don't have 386 Enhanced mode stuff at all, only Standard Mode. And again that'd go to a future DOS/386 project, not this.

Quote:

3. With the help of XMSDISK, several months back, I was even able to write a driver (basically, a .BAT file that required XMSDISK as an assistant) to move the Windows 9x operating system into RAM, and then instruct Windows to load it from the RAM drive rather than the actual hard drive, to increase performance. Of course, some data would still be read from the hard drive, and of course, copying the files to the RAM drive meant that it took a bit longer for the system to boot up than usual, but all in all, especially on more modern systems, it could easily save performance in the long run (by the way, I called this utility of mine "CACHEOS").

And how much performance is there to save with DOS? DOS is by itself lightning fast on modern computers so moving it to RAM would make only negligible difference.

Quote:

4. Possibly even have environments (such as a Windows 2.x-based version, a Windows 3.x-based version, and a Windows 9x-based version), where only enough of Windows is present to allow preemptive multitasking of many different DOS programs at once (in different windows), without any of the other portions being present (unless, in the case of a shared installation, the user were to load it at their own request, similar to typing "WIN" at a normal command prompt). Reading the antitrust documents reveals that Microsoft itself even had a similar idea at one point.

Again, that would go to a future DOS/386 project, not this. First this project should get done, and after it's done, I'm all for starting a companion DOS/386 project.

Actually, the Mini-Windows-based DriveSpace idea had nothing to do with the "DOS/386 project" idea (as you called it), but rather my idea to replace the current versions of DriveSpace and Disk Defragmenter that originally shipped with MS-DOS 6.x with more up to date and user friendly versions.

As for the CACHEOS idea, it was really about moving Windows into RAM - I was mainly suggesting its inclusion in the project, should the project itself ever be used alongside an actual Windows installation.

Finally, as for your other points, well, certainly, I agree that it's probably best to develop the normal MS-DOS portion first, and then develop the DOS386 counterpart later.

Also, I'm making progress with the Advanced API - I've decided to move it from INT 21h to INT EEh (which is unused in regular DOS), so I can have more possible AX values for the functions (each function has a unique AX value it's called by) and so I can also implement Unicode-backend variants of INT 21h functions 01 to 0Ah (input and output stuff). They'll work thus: a Unicode conversion table is loaded with another INT EEh function, then the INT EEh input function allow you to input in OEM then convert to Unicode, and the output ones take Unicode text and output in OEM, all according to the loaded Unicode conversion table. Said table is 512 bytes long.

Well, what I mean is to take the versions of Windows 9x's DriveSpace and Disk Defragmenter for Mini-Windows (along with the Mini-Windows files, of course), and use them to make a Mini-Windows-based DriveSpace and Disk Defragmenter for MS-DOS, complete with a genuine graphical user interface (provided of course, by the Mini-Windows setup).

This would even provide the ability to run DriveSpace and Disk Defragmenter as a Windows application, had the user decided to install Windows 3.1, rather than loading them from the Mini-Windows setup, and would essentially update both MS-DOS components significantly.

As you said, they would normally require Windows to operate. But, in this case, Mini-Windows is already supplied to run them in that mode, and it's just a matter of taking the Mini-Windows setup from the host drive of a compressed Windows 9x installation (preferably one with DriveSpace 3 support), creating a .BAT file to switch between two different sets of SYSTEM.INI files to either load DriveSpace, Disk Defragmenter, or both, from the command prompt, and also modifying Setup so that proper program groups are created for Program Manager in the case of this version of MS-DOS being used with Windows 3.1.

There. That's how I believe it should be done. And really, if it's from Windows 95 OSR 2.x or Windows 98, it would even add DriveSpace 3 support into your version of MS-DOS (provided, of course, that the code was updated to handle the DriveSpace 3 driver, if necessary).

Well, I just don't see why two DOS components should require any form of Windows to run. DOS should be self-sufficient and at most provide optional Windows versions of its tools. Also, the Windows 95 version of DriveSpace is equivalent to the MS-DOS 6.22 one, it's only in Plus! that it was updated to DriveSpace 3.