I have Windows 2003 server, with executable built on VC6. I would be needing to check the compatibility of the executable on Windows 2008 server (both servers 32 bit). I know that I need to check for ABI compatibility for these two versions.
How do I confirm that there is ABI compatibility for any two versions of a OS? Or does Windows release the ABI compatibility as part of product document?
Is there any other set of consideration to be taken care apart from ABI compatibility?
Windows maintains binary ABI compatibility between different versions. This means that programs do not need to be re-compiled for different versions.
However, this is not enough to guarantee that a program will run correctly on a version that you have not yet tested. Some examples of possible problems:
You use a deprecated API that has been removed in a later version.
You use an API that exists only on a later version of the OS and so your program fails to run on an older version.
The OS changes functionality that breaks your app. The classic example of this was UAC in Vista. The ABI did not change, but some pre-UAC apps failed to run correctly under UAC.
The bottom line is that you do need to understand the theory behind binary compatibility. But that does not absolve you of the need to test. Make sure that you've tested your program on all supported systems. Or at least as many as you can reasonably manage to find.
See detailed analysis of changes in the Windows API on this page. The reports are generated with the help of the abi-compliance-checker tool.
Related
I'd like to use some functions that are only available in Windows 7 or higher in my application but I also want my app to remain compatible with Windows XP. The app should check at runtime if at least Windows 7 is available and offer some advanced features (like Media Foundation support) in that case.
Is the only way to do this to manually check for Windows 7-only DLLs using LoadLibrary and then importing all the functions I need using GetProcAddress()? This would be very inconvenient but I don't see any other way. Statically linking against Windows 7+ DLLs will cause the application to refuse to start on XP because of missing DLLs so this won't work. But doesn't the Windows SDK offer some more convenient technique for programmers who want to remain compatible with older Windows versions and optionally use features of newer Windows versions?
Note that my application is written in plain C so I'm looking for a solution in C.
Don't ever check for OS versions. Check for available features instead.
The most convenient way to keep your code compatible with earlier versions of Windows while still allowing it to opt-in to newer features is to use delay-loading of modules (see Linker Support for Delay-Loaded DLLs). This allows you to benefit from import resolution as you would with compile-time dynamic linking, yet allows you to respond to import failures at runtime.
There are 2 options:
LoadLibrary / GetProcAddress. It is not so inconvenient - you can define and assign function pointers and use them like normal functions.
Compile 2 versions for XP and 7. The installer chooses the right executable or XP version is started by default and it runs second executable if OS is Win7.
First of all: I know that Windows XP is end of life, insanely insecure, a big risk and that everyone still using it will be doomed for ever.
Nonetheless I have to provide an application that can also run on Windows XP and I do so using Go.
In 1.10 it was announced that XP will no longer be supported and 1.11 confirms this in the release notes:
As announced in the Go 1.10 release notes, Go 1.11 now requires
OpenBSD 6.2 or later, macOS 10.10 Yosemite or later, or Windows 7 or
later; support for previous versions of these operating systems has
been removed.
I compiled my application with 1.11 and tried to execute it on a Windows XP SP3 virtual machine. It could be executed successfully !
Then I thought that the revoked support for Windows XP only applies to the development toolchain but even that can still be executed on Windows XP:
As you can see the main go binary still runs on XP too. Is it already known when it will no longer be possible to run golang compiled exes on Windows XP because of technical limitations or if certain methods will fail because they can no longer work because of missing APIs on XP ?
Issue #23380 is the relevant discussion.
In short:
Note that even if 1.10 is the last version to support XP, you'd get bugfix backports until 1.11 is out, and security backports until 1.12 is out. That means until January 2019 <…>
As to supporting Windows XP, there are both technical and non-technical reasons.
Supporting a platform requires:
Someone who has access to it, and an incentive to work on it
(either paid or unpaid).
The most active Go-on-Windows developer, Alex Brainman,
seems to have no interest in XP anymore.
This platform must be supported on autobuilders which are part of the Go release / QA process.
An autobuilder must be supported by someone.
Bugs specific to a platform must be fixed and tested.
For instance, that issue refers to #23375 which happens only on Windows XP (SP3).
But even if a bug was specific to Windows in general—as opposed
to Windows XP, a fix for it would have to be tested on XP anyway.
Hence, unfortunately, if there is no interest in supported Go on Windows XP coming from some "powerful entities"—such as corporations—the best you can do is to actually work towards still supporting this by yourself, FWIW.
Also note that even after the support is officially ended, you still might have success building newer Go releases from the source (which is reasonably simple since Go 1.5 as Go is now built using (an older release of) Go).
Hence a real show-stopper would be the Go team hitting some roadblock which would just require some kernel feature not present in Windows XP.
A good example was some difficulty with SEH handling on Windows 2000 which eventually led to dropping support for that OS.
Installed Windows on my Galileo board and that works fine.
I developed a small application i Delphi7 (32 bit exe) that
I have deployed to the Galileo and configured it to start
at boot by configuration in the autorun.cmd file.
start C:\applications\GalileoApp1.exe
The application is formless and contains a TCPserver that echoes back incoming data.
Works fine under windows 7 on my PC.
Does not start automatically or manually on my Galileo.
Has anyone tried something similar and succeeded in executing the application on Galileo?
Are there any limitations on what types of 32bit exe´s that can be executed on the Galileo?
Stock Delphi RTL will not work on that version of Windows. The primary reason is that the Galileo versions of Windows' DLLs are different from the desktop version. This will require a rebuild of the RTL in order to import APis from their new locations. Some APis aren't even supported (such as most of the ones in GDI32 and USER32).
That being said, here at Embarcadero, as a research project I have a version of the Delphi RTL that does run on the Galileo board (I'm looking at the board right now :). I also have a stripped down Delphi conversion of some of the Wiring/Arduino Sketch API. When or even if we release such a thing is purely dependent upon the demand and our intended product direction.
The bottom line is that, yes, it is possible to get a Delphi-built command-line application (no visual VCL is supported, or anything that assumes the presence of a GUI). No, it's not a straight-forward, simple process as it requires some significant modifications to the RTL. I would also not recommend using Delphi 7, since the Galileo board doesn't support most of the Ansi versions of the Windows APIs. You will need a Unicode capable version of Delphi to start with.
I have to develop a scanning application for the Canon 9000F, but I'm having troubles with WIA and TWAIN. I've read on the SANE project's home page that this specific scanner works pretty well with their technology, so I would be interested if it is possible to use the SANE backend on Windows platforms.
I found some information on this website: http://www.zago.net/sane/windows/sane_on_windows.html
SANE on Windows:
The port has been integrated in the CVS tree on september 23rd, 2003.
It will be available in SANE release 1.0.13.
Windows is also listed as platform on the SANE's wikipedia page:
Operating system: Microsoft Windows, Linux, UNIX, OS/2
In spite of this very interesting thread: sane runs in windows without cygwin I think that your only really viable option for using SANE on Windows is to use Cygwin or MinGW with MSYS. From the README.windows file:
SANE on Windows
Prerequisites
To be able to compile sane-backends, you need to have either Cygwin or
Mingw compilers and a suitable POSIX compatible environment.
You can get the Cygwin POSIX compatible environment for Windows
Windows and the Cygwin gcc compiler at http://www.cygwin.com
You can get the MSYS POSIX compatible environment for Windows and the
MinGW gcc compiler at http://www.mingw.org/wiki/MSYS
The scanner must be detected by Windows and not be disabled. Check
with the hardware manager.
Once you have either of those, you can untar and build SANE from the source code (check the readme for the required libraries) and it may or may not work with your Canon 9000F Scanner.
As you say, the chances are good that it will work as it is listed as supported under the pixma backend.
The difficult part was handled by TWAIN which is no longer an option as Windows moves forward. The SANE backends need to be built under Cygwin. Won't build with Mingw - no POSIX functionality.
I was wondering about the distribution rights of esent.dll (Extensible Storage Engine).
I know that it's included in Windows but, depending on the version of Windows, it's not the same.
For example, in Windows 2000, the initialisation is different and in Windows Vista+, there are some interesting parameters that were added.
So, instead of programming our software differently depending on the client OS, could we just take the latest version of esent.dll and distribute it with our software ?
In case you would get the permission ... how would you distribute it without problems to W2K, XP and so on ...
I doubt that you will be allowed to do that. Looking at Microsoft and its Windows OS you can see what an aweful burden legacy support can be. In a similar situation with ESENT I decided to just support Windows XP and for one part of my app only Windows Vista and newer, knowing that my customers are usually up to date. You could take a look into skipping support for at least Windows 2000. The ESENT API delivered with Windows XP is really powerful and you will hardly need the novelties of the newer versions.