I know that this is possible in principle, but the tools may not exist to do it:
Rather than booting up XP-Mode or some other VM to use Leydesforff's tools (http://www.leydesdorff.net/indicators/index.htm), I'd like a very thin command-line vm that I can use to just run a single 16-bit .exe file and pass input back and forth, i.e.:
vm.exe "oldthing.exe" -options ...
Or, any other way that I can write scripts (.bat, python, something like that) using these 16-bit .exe files that I can run on my Win7 x64 machine...
If they are DOS programs you can run them in DOSBox. It is a DOS/16bit x86 emulator writing primarily for games, but it should run any DOS application.
You can start it with a command line option indicating which application you want to run in DOSBox:
C:\Program Files\DOSBox-0.72\dosbox.exe" -conf "C:\Program Files\DOSBox-0.72\dosbox.conf" "C:\Games\Settlers 2\S2.exe"
Related
I am been currently studying AWS, and my online instructor uses "Windows PowerShell", however, I have always used "Hyper Terminal" for MERN stack. What is the difference between the two, and what sets this two apart from the Command Prompt?
Here is the simple answer:
PowerShell Preview replaced PowerShell, and PowerShell replaced Command Prompt (CMD).
Windows Terminal is an application that simply provides tabs to open multiple instances of PowerShell (Preview or legacy) and Command Prompt, as well as Azure cloud shell.
In Linux. you'll often hear the terms 'terminal' and 'console' used interchangeably, but they mean the same in Linux as they do in Windows. That is, console is the Linux alternative to the DOS style command prompt.
I am not familiar with Hyper Terminal but I see there are terminal emulators online that go by that name therefore I assume you may be using a third party terminal emulator.
PowerShell is a newer shell and also happens to be an object-oriented scripting language.
As far as Windows shells go, I can use PowerShell to do anything I used to do with CMD. Generally speaking, I would say PowerShell really shines when it comes to Windows System administration which is my primary use for it and it saves me a great deal of time.
As far as terminal emulators go, I feel the default terminals for both PowerShell and CMD are pretty much the same and are very lacking compared to 3rd party offerings or even the default terminal that comes in any modern Linux OS.
For a free "Microsoft" alternative to replace your default terminal, I would recommend the open-source "Windows Terminal" app. The addition of tabs, panes, zoom function, easy to read text, and easy ways to start different shells (such and CMD or PowerShell) or even start a WSL session with your choice of Linux OS is a major improvement to the default Windows terminal app.
We have a custom PowerShell script that calls into the BizTalk PowerShell Extensions, that needs to be invoked by a TFS Agent (from Release Management).
The thing is, the BizTalk PowerShell Extensions requires x86 mode, whereas TFS PowerShell on Target Machines task seems to be executing the PowerShell on Target Machines in x64.
Is it possible to solve this by using any of the below approaches?
By using some undocumented argument to the PowerShell on Target Machines task?
Have a x64 script invoke the 'real' scripts in x86 mode. I'm not really familiar with PowerShell, and it might be trivial to do, but I would need to figure out how pass my arguments to the x86 script.
Run the TFS agent service in x86 (e.g. via CorFlags)? I'm not even sure this would even work, and it feels dirty too....
SysWow64 technology allows you to execute 32-bit apps in a 64-bit environment.
On your target machine, please execute PowerShell scripts using the below the app
%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe
This would be the 32-bit version of PowerShell.exe and will let you execute your files.
In your batch file, you can make this configuration
I'm creating a standalone executable from MATLAB .m file using mcc.
My machine is a 64bit machine and the target machine is 32bit machine, is it possible to create such an application (and to be able to run it on the target machine of course)?
Probably the simplest way to do this is to install the 32 bit version of MATLAB and use the mcc from that installation.
Don't worry about the warnings that you get about installing 32 bit MATLAB on 64 bit Windows. It works just fine. I have lots of different versions of MATLAB installed on my machine for development purposes, both 32 and 64 bit, all happily co-existing side by side.
The documentation also mentions a -win32 option that can be passed to mcc:
-win32 Run in 32-Bit Mode
Use this option to build a 32-bit application on a 64-bit system only
when the following are both true:
You use the same MATLAB installation root (matlabroot) for both 32-bit and 64-bit versions of MATLAB.
You are running from a Windows command line (not a MATLAB command line).
Since you have to install 32 bit MATLAB, no matter what, it seems to me that it's just easier to run the 32 bit mcc directly.
I have a perl script on a linux system that I would like to compile to generate an executable that runs natively on Windows. I would like to do this with free software, preferably Perl PAR / pp. Is this possible?
You need to run pp on a windows machine to make a windows binary. I know it works, I've done it. Any Linux specific code will need to be made at least platform-independent or windows specific, but Perl is a generally platform independent language. Using File::Spec will help.
I am using cygwin 1.77 on windows vista.
I'm facing problems with the output from sbt in the shell.
Some relevant environment vars:
TERM=cygwin
CYGWIN=server
LANG=C.UTF-8
(1) When I type sbt test the shell contains a lot of unprintable characters:
How can I fix this ?
My sbt shell script looks like this:
dir=`dirname $0`
stty -icanon min 1 -echo > /dev/null 2>&1
java -Djline.terminal=jline.UnixTerminal -Xmx512M -jar
`cygpath -w $dir`/sbt-launch-0.7.4.jar "$#"
stty icanon echo > /dev/null 2>&1
(2) The sbt command cannot find the scalatest jar & I don't know how to configure it to download it via ivy. It works if I drop the jar into the lib folder.
Regarding 1):
The way the Cygwin console works is that there's a part of the Cygwin DLL that maps Unix terminal control sequences to Windows console API calls. Since that terminal emulation is part of the Cygwin DLL, it is not available to non-Cygwin programs such as the Java runtime. Instead, java will be talking directly to the Windows console, which doesn't understand escape sequences. Hence they appear directly on screen.
There are a few ways you could address this:
Tell Java/Scala to use the Windows console API instead of Unix control sequences. I guess removing the -Djline.terminal=jline.UnixTerminal option would do that.
Set the CYGWIN=tty option. With that, programs invoked in the Cygwin console have their I/O connected to a "pseudo terminal" (pty) device instead of being connected directly to the console window. This makes the terminal emulation features available to non-Cygwin programs, but it means that programs that use the Windows console API will no longer work correctly.
Use one of Cygwin's other terminal emulators: mintty, xterm, rxvt(-unicode). These offer better terminal emulation and more sensible user interfaces than the default console, but again at the cost of not supporting programs that use the Windows console API.
(Btw, the CYGWIN=server option is obsolete; the feature that it enabled is always on anyway.)