Code View not working

[HSE]

I don't know 

[Ravi Kiran]

Hi Ravi,

Welcome to the Forum

Please define "is not working directly": Does it run at all? Do you get error messages?

As far as CV.EXE is concerned 'not working' means. I'll explain it below.

At the command prompt when I type CV.EXE as shown below
C:\>MASM611\BIN\CV.EXE
it either returns to C:\>MASM611\BIN\ without displaying anything or
Sometimes it displays an external Windows message displaying
"The NTVDM.EXE has stopped unexpectedly".

I've attached the screenshot of error message as zip file.

[Ravi Kiran]

Not only consensus but also common sense. 
But you may be right, who knows? Microsoft does not publish statistics about that and our data is mostly obtained from internet browsers. 
But don't forget that virtually all hardware is 64-bit ready. What sense does it make to install a 32-bit OS on that hardware when it can run both 64-bit and 32-bit software?

I'd install 64-bit Windows OS as soon as possible sir.

[Ravi Kiran]

Windows 32-bit support 16-bit applications.

Exactly sir the image which you have shown above is not getting
displayed when I click CV.EXE directly from Windows.

[aw27]

Hello Ravi,
This is just speculation, may not be the reason. Try to use an older release of CV.exe (I used 3.14) because more recent ones may need special configuration because they they support protect mode 286 and 386 (that old stuff called hymem.sys, emm386.sys, etc, we inserted into the config.sys). Remember that Virtual Mode x86 is not exactly a true MS-DOS environment. To have an MS-DOS replica from the old days use a Virtual machine, like Virtual Box or vmWare, and install MSDOS on it.

[jj2007]

Sometimes it displays an external Windows message displaying
"The NTVDM.EXE has stopped unexpectedly".

NTVDM is the 16-bit subsystem on a 32-bit Windows version. If it stops "unexpectedly", CV caused an exception. Bad luck - as others have suggested, try another version or use a VM. Why do you want to code in DOS anyway? Some think (erroneously) that 32-bit is obsolete, but 16-bit code is definitely a thing of the past.

[mineiro]

The processor boots in real mode when we turn on the machine. There are other modes. In 32-bit mode it is switched to private for some security and then to long (64-bit).
Codeview was made for real mode, to work in ms-dos, this means 16 bits initially and a different command interpreter than cmd.exe; instead, command.com.
If you make a boot disk with the basics of ms-dos it will work if you put it on the floppy disk and change setup settings; or, if a cd-rom, if bootable, you can even copy a virtual mini disk if you can mount the system drive or perhaps in memory.
One problem that can happen with debuggers that use command.com interrupts (command interpreter) instead of cmd.exe (command interpreter) functions are the functions they offer. Addiction and monopoly rather than virtuosity.
The Operating System offers us (as programmers) functions, and at that time was done through interruptions. The ms-dos offered us the 21h interrupt, a conglomeration of instructions that made use of the bios functions or directly changing bios variables in memory, the initial machine, the base. The problem was that the interruptions (which certain hardware offered) from a programmer's point of view were not so widespread.
If you can reproduce virtually or really the past, the program will work; due to the fact that processor instruction compatibility may not be from bios.
It worked in dosbox because it offers ms-dos "functions", while cmd.exe does not, I mean, not interrupt.
One caveat, some programs use undocumented functions (interrupts). This was common at the time of word and excel as it was anti-monopoly. I've seen some programs only work on the microsoft virtual machine (int 2eh) and not others.
I know other modes of processor operation but unfortunately I forgot how to proceed.
Summary is; If you offer everything the program needs to work, it will work.

[Ravi Kiran]

Sometimes it displays an external Windows message displaying
"The NTVDM.EXE has stopped unexpectedly".

Thank you very much for your kind information sir . I'll switch to 32-bit
programming as soon as I'm done with this 16-bit suff.Any how for some time I'll use 16-bit stuff for learning and knowledge sake because I'm a student and beginner of Assembly language programming.

NTVDM is the 16-bit subsystem on a 32-bit Windows version. If it stops "unexpectedly", CV caused an exception. Bad luck - as others have suggested, try another version or use a VM. Why do you want to code in DOS anyway? Some think (erroneously) that 32-bit is obsolete, but 16-bit code is definitely a thing of the past.

[Ravi Kiran]

Sometimes it displays an external Windows message displaying
"The NTVDM.EXE has stopped unexpectedly".

Sir I even have the 64-bit Command line version of MASM ie ML64.EXE and it's Associated libraries. But what is the use of it unless I know the 16-bit and 32-bit  Assembly language perfectly.

Even if 128-bit Computing Comes in to Effect there will be some
missing points in 16-bit Computing and I think that 64-bit Computing
Is some what based on the Concepts of 32-bit Computing and 16-bit
Computing.

NTVDM is the 16-bit subsystem on a 32-bit Windows version. If it stops "unexpectedly", CV caused an exception. Bad luck - as others have suggested, try another version or use a VM. Why do you want to code in DOS anyway? Some think (erroneously) that 32-bit is obsolete, but 16-bit code is definitely a thing of the past.

[Ravi Kiran]

Windows 32-bit OS are rare these days, like Indians in America. We conserve 32-bit OS in reserves called virtual machines to prove that Codeview works in them.

Yes sir most of the Indian Software Engineers don't even know
that Assembly language was Existing still in 2020.

[Ravi Kiran]

The processor boots in real mode when we turn on the machine. There are other modes. In 32-bit mode it is switched to private for some security and then to long (64-bit).
Codeview was made for real mode, to work in ms-dos, this means 16 bits initially and a different command interpreter than cmd.exe; instead, command.com.
If you make a boot disk with the basics of ms-dos it will work if you put it on the floppy disk and change setup settings; or, if a cd-rom, if bootable, you can even copy a virtual mini disk if you can mount the system drive or perhaps in memory.
One problem that can happen with debuggers that use command.com interrupts (command interpreter) instead of cmd.exe (command interpreter) functions are the functions they offer. Addiction and monopoly rather than virtuosity.
The Operating System offers us (as programmers) functions, and at that time was done through interruptions. The ms-dos offered us the 21h interrupt, a conglomeration of instructions that made use of the bios functions or directly changing bios variables in memory, the initial machine, the base. The problem was that the interruptions (which certain hardware offered) from a programmer's point of view were not so widespread.
If you can reproduce virtually or really the past, the program will work; due to the fact that processor instruction compatibility may not be from bios.
It worked in dosbox because it offers ms-dos "functions", while cmd.exe does not, I mean, not interrupt.
One caveat, some programs use undocumented functions (interrupts). This was common at the time of word and excel as it was anti-monopoly. I've seen some programs only work on the microsoft virtual machine (int 2eh) and not others.
I know other modes of processor operation but unfortunately I forgot how to proceed.
Summary is; If you offer everything the program needs to work, it will work.

Nice Explanation sir. Thank you very much for your kind information.
I'll try to solve the problem all by myself based on the info you have
Provided.