Good afternoon Brent - thanks for the lengthy discussion! I come from the pre-Windows era (DOS 5 and on) and can confirm 99% of everything you stated below. I was, however, unaware that newer CLI executables were not actually still DOS-based but instead linked against Windows .dll files. What a shame! I was hoping that such a basic command such as the modern chkdsk.exe would be able to use something like dosemu to work. I am not sure that wine will fit into part of the project (since it is command line only). The other side of it is graphical and will therefore run X.org so wine could be a solution. I will probably still attempt to see if by chance chkdsk.exe will run under dosemu, although it is not looking good at this point per the discussions with everyone. I will report back my findings just so everyone can have confirmation one way or another - unless someone already has a working dosemu and can quickly attempt a chkdsk run with it (I will have to compile dosemu for my distro before attempting anything). Thanks again to everyone for the conversation - it was enlightening! Dave On 9/24/18, Brent Busby <brent@xxxxxxxxxxxxx> wrote: > David Henderson <dhenderson@xxxxxxxxxxxxxxxx> writes: > >> Good morning! You are correct that multiple people have mentioned >> that, and it may be true. I do know that chdsk can run during the >> boot cycle which does not yet have a graphical environment to run, >> hence my thoughts on it being a console based executable. I will play >> with it to see if that is indeed the case, or it if is as the others >> have stated that it is not. I'll report back once I get things going. >> It will require me to compile dosemu for this particular distro >> through, so a couple of extra steps are required... >> >> Keep your fingers crossed people!!! > > I'm certainly not an expert on dosemu or DOS internals, but I think the > mistake you may be making here is assuming that because CHKDSK is a CLI > program, that it's DOS. That would have been a poor assumption even in > the days when Windows was DOS-based (95/98/ME), but an even poorer > assumption for a program that can fix NTFS filesystems, typically found > on Windows versions that are not DOS based at all. > > It is completely possible for a program in Microsoft-world to have no > GUI, run in a command prompt window, be batch-scriptable, and still be > linked against Windows DLL's, assume that Windows is running, and > basically be in all respects a WIN32 executable that DOS could not > support. In fact, as more and more time goes on (and the Age of DOS > recedes into the past), this becomes more certain of just about any > Windows CLI program you run into. > > When Windows started, it was a GUI that sat on top of DOS, and a lot of > it depended on DOS, but even then, a CLI-only yet Windows-native program > was possible. One of the purposes of Windows NT (as compared to > previous versions of Windows) was to create a new form of Windows that > would have no DOS underneath it at all. Since it is NT which gave us > NTFS filesystem, any program that can fix NTFS problems would be > expected to come from that world, the world of NT-based Windows flavors > where DOS does not exist. (And no, the CMD.EXE command window offered > on NT-based Windows versions is not really MS-DOS, much as it strongly > resembles it.) All modern Windows flavors (NT/2000/XP/Vista/10) are > descended from this NT-based form of Windows that does not have any true > DOS in it. It is highly unlikely you could get any EXE files from these > OS's to run from a DOS prompt, even on real PC hardware running real > DOS, even if they were CLI programs. > > It's a long shot, but if anything, you might have more luck trying to > run CHKDSK on Wine than in dosemu, since at least Wine is meant to run > WIN32 executables, and wouldn't necessarily need them to have a GUI. I > think probably the only reliable way to do a full repair on an NTFS > partition on UNIX would be in a full virtual machine session running > Windows in the VM (QEMU, Xen, VMware, etc.). >
