I am working on the a project that requires me to run a Makefile which calls on several 16-bit .exe scattered in my F drive. I have looked into using otvdm (aka winevdm) to run the 16-bit applications though I am looking for a way to get them run to automatically when a called on. The current setup of otvdm is having manual selection from the user. What I want is when a 16-bit application is called, it would use otvdm to run the application without me getting involved. Looking for ideas to do this or work around it?
My 64-bit Windows 10 OS rejects any 16-bit applications from running.
From the readme at https://github.com/otya128/winevdm .
How to install
Download or compile
Run "install" shortcut or right-click on install.inf and select "Install"
You can execute Win16 binaries directly!>
If the registry is initialized by Windows Update, perform the above procedure again.
You can uninstall it by running uninstall.reg.
You probably want to use the (no console) link.
Related
Has anyone been successful at packaging a Gtk3 app for Windows for the Microsoft store?
I'm playing with this at the moment:
Visual Studio 2019;
Gtk3/Gtkmm distro obtained via vcpkg;
C++ app;
VS Application Packaging Project.
The application runs fine on its own. I then package it, and then run the MSIX bundle installer. When I then run the installed application, it starts but:
an Access Denied error appears in a dialog box;
the application appears with broken icons and incorrect colors (wrong or no theme).
I have tracked the error having to do with Gio-2.DLL where it attempts to spawn a child process, looks like something to do with creating a dbus server/session (??). I believe the child process (dbus server?) starts but then attempts to do something that is not permitted in the sandbox that Windows creates for the app.
Anyone?
After some more investigation, I may have found a workaround. I'll post it here in case it helps anyone else. This workaround allows making a packaged Gtk3 application for Windows. A Windows packaged application runs in a sandbox of sorts, with heavily restricted access to resources outside the package.
First, the issue: during initialization, the version of Gio-2.DLL for Windows spawns a child process to serve as a DBus session daemon (I may get the terminology wrong here as I'm not that familiar with DBus). It does so only for the first instance. If one launches additional instances of applications that use Gio-2.DLL, the additional instances use the existing daemon from the first instance.
To launch the daemon, Gio-2.DLL calls CreateProcess() to fork a RUNDLL32.EXE child, with the full path to Gio-2.DLL (i.e. itself), and g_win32_run_session_bus() as the name of the function to call. It looks like RUNDLL32.EXE does launch successfully, since it is able to display the "RUNDLL" error dialog box. However it fails to make the requested function call into Gio-2.DLL. I gather that at least one of the system calls that RUNDLL32.EXE makes to load the DLL and call the requested function is prohibited when running in a packaged application.
At the moment, my workaround is this. Assume my application executable is called 'myapp.exe':
the application package contains myapp.exe, all the necessary DLLs for Gtk3 and dependencies, and another executable 'dbus_daemon_launcher.exe';
before entering the Gtk main loop, myapp.exe calls CreateProcess() to start dbus_daemon_launcher.exe;
dbus_daemon_launcher.exe is also linked with Gio-2.DLL and makes a call to g_win32_run_session_bus() with the DLL;
myapp.exe then proceeds to start the Gtk main loop. Since the Dbus daemon is then already running, Gio-2.DLL does not attempt to call RUNDLL32.EXE to launch it, which avoids the error.
This workaround has the advantage that it does not require making a custom version of Gio-2.DLL. Also, I'm using Gtk3: perhaps this issue has been addressed in the more recent Gtk4, and the workaround is unnecessary in this case.
I've written some application code using JMF, but would like to switch to FMJ to make delivery easier.
Unfortunately, on my Windows 7 laptop (where JMF works fine once installed), I downloaded fmj-20070928-0938.zip, uncompressed it, and ran fmjstudio.bat. As soon as I click on the webcam icon, I get errors which start with "WARNING: com.lti.civil.CaptureException: java.lang.UnsatisfiedLinkError: C:\Temp\fmj-extracted\native\win32-x86\civil.dll: Can't find dependent libraries"
Any suggestions?
Although it is probably not a complete answer, a partial answer is that FMJ uses 32-bit libraries. I am fairly sure I was using a 64-bit java.
On a different Windows 7 computer I successfully got fmjstudio to run using a 32-bit java. Next step is getting it to recognize the camera for my own app rather than fmjstudio.
We have an application which, for various reasons, needs to be compiled as both a 32-bit and 64-bit app. The thing is, we want to distribute both setup files (msi) on a single CD. Is there a launch condition or autorun.inf entry that we can use to know which setup.exe to launch? Or do we need to write a separate little exe that gets called by autorun, and which determines the OS, and calls the appropriate setup.exe?
There does not appear to be any 32/64bit detection support inherent in autorun.inf files.
The convention that most applications which supply a 32 and 64 bit MSI follow is similar to the second option you mention.
Create a single 32bit setup.exe application (so that it will run on either platform). Ideally this will be written in C/C++ so that it is as small and quick as possible, and has no dependencies on other libraries/frameworks (eg. static linked).
Detect if you are running on 64bit or not (see sample code for Windows API IsWow64Process function
Execute the appropriate MSI
You can use a custom action to detect the OS, then call the right installer.
I've given an example here: Single MSI to install correct 32 or 64 bit c# application
I have a Win7 PC in use as part of an experiment control system. The experiment in question uses 4 windows simultaneously, and I would like to find away to open, position and size these 4 windows with a script.
The script would run at start up, so that the newly booted PC presents the user with the four windows as default.
Obviously I can use a batch file in the startup folder to open windows and run applications, but is there a way to specify the layout of these windows?
Many thanks
Si
Assuming that you have access to a scripting language that supports making calls to Windows API functions it shouldn't be too hard. Otherwise I'd suggest writing a small executable in some language (at least any of C++, C# or VB.Net would all work fine) and have that do it.
You could use FindWindow, as described here, to find the windows and MoveWindow, as described here, to move them around.
I use an AutoHotkey script to set up all my environment (around 7 windows in 3 different virtual screens), works pretty well. You can set the location of windows etc.
I can use a batch file to open the apps, then run WiLMA to relocate them
We're running our unit tests as a post-build step in our builds. Now I've run into a problem with this on our autobuild machines that automatically pull and build every revision in svn.
The autobuild script pulls down a revision, does some setup and then calls devenv.exe /build on it. This, in turn, will build everything and then try to run the tests. The build gets stuck and never completes.
If you build the solution manually, what happens at the run tests point is a popup dialog box saying the test executable is not a valid Win32 application. I'm assuming the autobuilds somehow get this box as well, but hidden away in a non-interactive session somewhere.
I've had two ideas for a solution this far:
Check in a test-runner application which tries to run the tests and detects the failure. This is undesirable though since this would mean creating this extra kludge of code and adding it to be used only on windows builds etc.
Somehow test if windows is 32-bit or 64-bit in the build scripts (we're running cmake), and simply don't run the tests if they wouldn't work. This is preferable, but requires a way of checking if windows is 32-bit or 64-bit, preferably without having to check in another "test-windows-type" helper tool.
Any further ideas or hints on how to implement suggestion 2 would be much appreciated.
Update: Note here: This is a cross-compile running on a 32-bit machine but compiling a 64-bit exe. If I could just check properties of the compiler, there wouldn't have been a problem. But I'm after properties of the build machine, not of the build itself, which is clearly 64-bit.
Check the %PROCESSOR_ARCHITECTURE% environment variable :
x86 on a 32-bit machine.
AMD64 on a 64-bit machine (cf. here).
You should be able to check the CMake generator which I think is different for 32/64 bit windows.
Not an answer to the the specific question you asked, but you should perhaps consider building your app on an x64 machine, which could run 32-bits tests as well as 64-bits tests...
You can check the CMAKE_SIZEOF_VOID_P variable in your build script to detect the type. See documentation here. Then you can skip running the tests if this variable is 32.
Update: Sorry I overlooked your real issue. I think the best approach may be to apply a try-run test and use the RUN_RESULT_VAR to determine if the app ran successfully.
I found out one way to identify if the system is 64-bit or not, which should be possible to access from cmake. It feels as a rather ugly hack though that could break on any random version of windows, so I'd still rather find another way.
The %ProgramFiles(x86)% environment variable only exists in 64bit OS versions.