Sir I've deliberately installed 32-bit version of Windows 7 Operating
System to Study what's going on in a Computer and to study Assembly Language. But I'm encountering some problems while
Doing so. The MASM611's CV.EXE Executable is not working directly in cmd.exe which comes with Windows 7. But it works through
DosBox-0.74. Can anyone tell me how to resolve this issue.
I'm sorry to remind you sirs I'm a student and beginner of Assembly
language. I'm beginning it from 16-bit DOS programming. You may joke about me for using 32-bit version of Windows even though now-a-days processors are 64-bit. I can install a 64-bit version of Windows
in a different Storage Device alongside 32-bit Windows 7 but a 64-bit Windows does not Natively support a
16-bit DOS Application. That's why I've deliberately installed a 32-bit
Version of Windows 7 for studying about paging and memory management features of IA-32 Architecture through Windows.
Because a 32-bit Windows supports exactly 4GB of Flat Address
Space installing a 4GB of Physical RAM is easy. For a 64-bit Windows
Mapping a linear Address space to Physical RAM Addressing is very
Complex because a 64-bit Address space can address up to 2^64
Bytes and who could install a 2^64 bytes Physical RAM. Any how I'm
Absolutely new to Memory mapping and Paging features in Intel
Processors as of now.
You may joke about me for using a 32-bit Windows but I don't feel angry about that.
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".
Hi Ravi,
Welcome to the Forum :thup:
Please define "is not working directly": Does it run at all? Do you get error messages?
cv is a 16 bit tool, that is not supported by W7
Windows 32-bit support 16-bit applications.
(https://www.dropbox.com/s/ndus6o26lk5zg2h/codeview.png?dl=1)
Ok, 16 bits applications are not supported by at least my W7 64 bits in my laptop and don't know if there is anything that allows to do so :toothy:
I'm sorry, this reminds me a joke: :bgrin:
Quote
An astronomer, a physicist and a mathematician who were traveling on a train through Scotland saw a mottled cow in the middle of a field by the window. "How interesting," said the astronomer, "all Scottish cows are mottled." Upon hearing it, the physicist responded. "No!, Some Scottish cows are mottled." Upon hearing what they said, the mathematician said reproachfully "In Scotland there is at least one field that contains at least one cow, which has at least one mottled side."
Give up on the old 16 bit CodeView, it was a great debugger in 16 bit real mode but will not work in 32 or 64 bit protected mode. For Win32, get a modern debugger that is compatible with 32 bit Windows protected mode.
Quote from: caballero on December 28, 2019, 12:11:36 AM
Ok, 16 bits applications are not supported by at least my W7 64 bits in my laptop and don't know if there is anything that allows to do so :toothy:
Apparently, in 7-32 bits depends on program screen mode.
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.
Quote from: AW on December 28, 2019, 12:38:21 AM
Windows 32-bit OS are rare these days.
Where you found that data?
Thanks in advance.
Quote from: HSE on December 28, 2019, 01:09:53 AM
Quote from: AW on December 28, 2019, 12:38:21 AM
Windows 32-bit OS are rare these days.
Where you found that data?
Thanks in advance.
This is a consensus (what I mean is that I will not search the web for you in this regard) and values are in the order of 97% or more for Windows 64-bit OS. If you disagree, please prove they are wrong.
Quote from: AW on December 28, 2019, 01:24:45 AM
This is a consensus...
Consensus is a political agreement, not necessarily related with true.
Some web sites have statics of OS access, but I don`t know if are published somewhere.
Quote from: HSE on December 28, 2019, 01:44:03 AM
Consensus is a political agreement
No, no, there are also consensus about anthropogenic climate changes. Remember?
Quote from: AW on December 28, 2019, 02:43:05 AM
Quote from: HSE on December 28, 2019, 01:44:03 AM
Consensus is a political agreement
No, no, there are also consensus about anthropogenic climate changes. Remember?
:biggrin: It's same case!! Claim consensus to hide lack of facts.
Not only consensus but also common sense. :biggrin:
But you may be right, who knows? Microsoft does not publish statistics about that and our data is mostly obtained from internet browsers. :badgrin:
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 don't know :biggrin:
Quote from: jj2007 on December 27, 2019, 06:41:55 PM
Hi Ravi,
Welcome to the Forum :thup:
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.
Quote from: AW on December 28, 2019, 04:06:29 AM
Not only consensus but also common sense. :biggrin:
But you may be right, who knows? Microsoft does not publish statistics about that and our data is mostly obtained from internet browsers. :badgrin:
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.
Quote from: AW on December 27, 2019, 11:46:02 PM
Windows 32-bit support 16-bit applications.
(https://www.dropbox.com/s/ndus6o26lk5zg2h/codeview.png?dl=1)
Exactly sir the image which you have shown above is not getting
displayed when I click CV.EXE directly from Windows.
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.
Quote from: Ravi Kiran on December 28, 2019, 07:40:40 AMSometimes 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.
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.
Quote from: jj2007 on December 28, 2019, 09:50:22 AM
Quote from: Ravi Kiran on December 28, 2019, 07:40:40 AMSometimes 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.
Quote from: jj2007 on December 28, 2019, 09:50:22 AM
Quote from: Ravi Kiran on December 28, 2019, 07:40:40 AMSometimes 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.
Quote from: AW on December 28, 2019, 12:38:21 AM
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.
Quote from: mineiro on December 28, 2019, 01:43:19 PM
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.