I need to use MASM 6.11 for Assembly Programming in my college. I'm using OSX 10.9.1 and have installed Dosbox 0.74 via homebrew.
After completing MASM 611 setup on Dosbox. When I try to run MASM MASM611\bin\MASM I get a segfault, and dosbox crashes.
After searching through forums, I tried running MASM 5.0 instead and it seems to be working fine.
Is there anyway to get MASM 6.11 working on dosbox?
Update
Autoexec section of my DOSBox preferences
[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
MOUNT C ~/DOSBox
SET PATH=C:\MASM611\BIN;%PATH%
SET LIB=C:\MASM611\LIB;%LIB%
SET INCLUDE=C:\MASM611\INCLUDE;%INCLUDE%
SET HELPFILES=C:\MASM611\HELP\*.HLP
SET TMP=C:\TEMP
C:
MASM.EXE or ML.EXE version 6.11 probably needs the dos extender to be in a directory in the "path". The Microsoft version of this is named DOSXNT.EXE. Make sure that the bin directory that you installed MASM / ML 6.11 into is added to the path environment variable.
Another option, if you can't get DosBox to work, is to try running MASM on FreeDOS inside VirtualBox.
Related
I downloaded visual code 1.60.2 for windows 7 . My pc has 32 bit operating system.When i downloaded vs code and ran the code it shows up"'gcc' is not recognized as internal or external command".
Please tell me what should i do.
You have to install a MINGW Environment in order to use gcc with Windows.
Steps:
Install C/C++ extension for VS Code
Install Mingw-w64
Add mingw bin path to your PATH variable in windows.
If you have already installed the extension and mingw, you forgot to add it to the path variable. Validate this with opening a Commandline or Powershell an call:
g++ --version
Here is a detailed guide how to do this: Using GCC with MinGW
Recently, Intel released Ifort compiler for free, for everyone to use. As I have been using gfrotran for quite some time, I decided to install it. I installed the two packages that intel says they are needed (using Windows 10). In the console, as ifort was not recognised (I tried to set up the path to the executable ifort.exe to no avail), i decided to use intel one api tool console.
In that console, ifort is recognised, and you can acces help options and the likes. However, when I try to run a simple test program, it runs with fatal error LNK1104, where imageHlp.lib is missing.
I also tried to run it form the VS17 interface, but it was futile.
I don't know what I am doing wrong, and Intel support forums are in permanent "we are experiencing network issues".
I just want to compile a text file to an executable, no libraries involved, nothing fancy.
I am not seeing any issue with the Intel forums. Make sure you have configured VS2019 for the "C++ Desktop Workload" - see https://software.intel.com/content/www/us/en/develop/articles/installing-microsoft-visual-studio-2019-for-use-with-intel-compilers.html Or for VS2017, https://software.intel.com/en-us/articles/intel-c-fortran-compilers-for-windows-integration-into-microsoft-visual-studio-2017
After you have installed the oneAPI HPC Toolkit, there is a shortcut created Intel oneAPI > Intel oneAPI command prompt. Use this to establish the environment. But you will probably find that the default directory with that shortcut is C:\Program Files (x86)\Intel\oneAPI, which is unusable for compilation, so "cd" to a writable directory. (I like to copy that shortcut to my desktop and modify the "Start in" location.)
Well I am relatively new in computer's world, and I learned programming on a virtual machine using linux S.O. I am using minGW32 command prompt, and I can compile and run my c codes as needed, however I recently installed gdb debugger (for debugging my programms), and it is bit uncomfortable to write:
"c:\mingw\bin\gdb.exe" exe_name
in order to debug my programs. Is there a way for having something like:
gdb exe_name
like in linux?
Thanks in advance.
extra question: And the same for valgrind?
best regards
You should add the path "c:\mingw\bin" in your environment variable. This way whenever you type gdb on command prompt, it would search from the above path.
And the same for valgrind?
Till date Valgrind does not run on Windows platform.
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
I'm having some trouble installing and configuring qt on my vista laptop.
I'm trying to setup a development environment on my laptop where I compile from the command line, because that's how the environment is setup on my university's linux machines, so I don't want to tie myself to some IDE .. (plus, real programmers use the command line!)
I haven't used the command line before for C++ development, it was all MSVC, so now I'm having a bit of trouble.
I'm still using MSVC, but from the command line. I practically have no idea what's going on, I just know that I have to run:
qmake
nmake
to compile my code!
I downloaded the opensource version of qt, and did the configuration, and tried a simple qt application (from a tutorial) and it worked, it compiled and executed pretty much as expected.
Now, when I decided to run another project that uses opengl, I got the following error:
fatal error C1083: Cannot open include file: 'qgl.h': No such file
or directory
I'm not sure where does the compiler look for header files, and I didn't copy any header files anywhere, I assume that configure.exe worked its magic somehow and added the include directory to one or more enviroment variables or to some registery location or whatever other peculier places that the MSVC compiler searches for to find include directories.
However, what I did was search my C:\qt\include\ folder to make sure that qgl.h exists, and sure enough there it was. so why can't nmake find it?
I think the actual solution to this is in your pro file:
QT += opengl
If you want to stay with the command line anyway (plus use it on a linux box later / parallel) I'd suggest at least trying out the MinGW version of Qt. I'm using it regularly, and besides of the non-existance of a GUI it works pretty well. Using MinGW also has the advantage that you can simply download and install the MinGW edition of Qt and don't need to reconfigure or recompile anything.
Also, trying out QtCreator might be interesting. It's still beta and requires the beta Qt 4.5 but it's a nice small IDE that integrates nicely with gcc.
Two potential solutions (they solved issues at my workplace)
Do you have qt include and bin folders in the PATH variable? I think the doc says only one of these is needed, but one of the students had Vista and putting the other in the PATH variable solved a "Cannot open include file" problem.
If you're using MSVC did you run configure and nmake from the Visual Studio command prompt? We had problems when using the bare windows Command Prompt because the VS one adds a lot of temporary environment variables to the configure process.
Good luck
Install the complete Qt SDK for Windows which includes Qt 4.6 SDK, Qt Creator 1.3, and MinGW.
It will also install "Qt Command Prompt" launcher that you can use to build Qt apps from the command line.
I'm sure you're more familiar with MSVC than MinGW, as I do too (I've been using MSVC 6.0 to MSVC# 2008 for developing .NET apps).
But try MinGW with Qt and I think it's better for long term. I do some C++ development on Linux too so getting familiar with MinGW will be beneficial for you in cross-platform C++/Qt development.
For more info, see Installation of Qt 4.6 SDK for Windows.
Qmake generates Makefile from *.pro file located in current directory. It has qt path compiled in. Type "qmake -v" to see it. You can't move qt's dir after compiling it. If You haven't moved it, first maybe try to install Qt following instruction from INSTALL file. Good luck.
The opensource version of Qt does not provide profiles (mkspecs in qt terms) so qmake can generate nmake (msvc) compatible makefiles.
You have to use mingw/gcc.