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.
Related
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.
tl;dr: Device driver written in NuMega DriverStudio for Win95 to be upgraded to Win10 64-bit. What's the easiest path?
We have a very old product line, which is still selling well. One dll, accessing a UART in a way normal serial handlers can not (to support an even older protocol for another company's products), was made back when the product was first released - for Windows 98! Ever since, it has been working flawless (on 32-bit machines). Therefore, the code has never been touched since it's initial creation!! (This is based on the memory of a few of my colleagues who were around at the time). The only source I have been able to find is from 2001, although one file dates back to 1998.
The driver type is WDM
Now Microsoft have stopped providing 32-bit versions of Windows 10, and customers have started asking for a 64-bit version of our software, so I landed the task of figuring out how easiest to fix it - and support win7 through to Win10, 64-bit.
However the DriverStudio from NuMega was discontinued shortly after the company was purchased by Compuware (and they have lost all knowledge of it!), and even if we were able to find an old version (latest is from 2002), it's unlikely that it's going to help us very much.
I've been searching the web, but haven't found anything giving any suggestions to what the then users of DriverStudio did to upgrade their drivers.
At the time, Jungo WinDriver were an alternative that most people didn't consider to use for 'real' drivers, but perhaps times have changed?
Any advice on how to upgrade this driver code as easy as possible will be highly appreciated.
Starting with Windows 8.1, GetVersionEx no longer returns the "true" version number, but might return a lower value.
There a no service packs for Windows 8 or Windows 8.1 yet, but when they are available, will GetVersionEx lie about them (wServicePackMajor and wServicePackMinor in OSVERSIONINFOEX) as well?
Microsoft forever does battle with well-intended code that a programmer writes to check the Windows version. Which was typically written to deal with older Windows versions. But forgets to do something reasonable with a newer Windows version.
So they spend massive amounts of effort on targeted compatibility shims that intentionally lie about the Windows version when a specific program asks for it. A never-ending battle whenever they release a new Windows version. Certainly a losing battle, the number of programs they need to test is staggering.
So at Windows 8.1 they said "no more", deprecated GetVersionEx() and intentionally lie out of the box, returning version 8.0. You need to add an entry to the manifest to turn off the lie. Which probably will turn off a lie about the service pack as well. Or might require an updated GUID, fairly unlikely. We of course can't be sure until that happens.
we have a small app that doing trivial stuff, no GUI.
we was using Linux, but the library/framework available for Linux is highly less than that for windows, it was such a pain to develop under Linux.
So we want to use windows, but windows is too big for the trivial app, is there any solution that i can use windows and not losing OS's lightweight?
any advices appreciated.
What kind of applications are you building?
1) some older versions of windows have less bloat, but you wouldn't want these running on public networks because they don't get security updates. Plus, the latest/greatest libraries may not run on them
2) If you're running command-line server utilities, you could try Windows 2008 Server Core, which is a console-only installation
3) You might want to try Wine or Mono to run your windows/.NET framework-based application.
You should try a "Windows PE" (sometimes also called "minint") installation (installation guide here), which is a trimmed-down version based on Windows XP or Vista.
This does not make sense, sorry. If you have a CLI program under Linux why shouldn't you be able to write on CLI program on Windows?
I am looking for a recommendation on an installer program. The installer needs to support mulitple OS's - Solaris, Linux and Windows. I have three build machines each running one of the OS's. Currently using the same code base - JAVA and C/C++ for all three.
InstallAnywhere seems to be the dominant player.
IzPack is a an open source software installer generator. All you need is a JRE on the target platform.
Maybe is my personal opinion but I think that the installer is probably the only thing that you may want to keep platform specific and here is why:
it is good to integrate with platform specific deployment systems like: RPM or DEB on Linux, DMG on OS X or MSI under Windows. By using them and allowing both UI and silent installation you will easy the installation of the product for individuals and also for enterprise environments - where it's common to push the installations to the clients.
you can add move the configuration screens outside the installer and trigger them first time when the user runs your application
also do not forget to minimize installer complexity - each "feature" you add will cost you more specially on QA.
You can take a look at BitRock InstallBuilder It supports all the platforms you mention, and it does not depend on Java (though you can use it to install Java programs, in fact many of our customers use it for that, including Sun Microsystems :)
Does it need to be a client-based installer for wide distribution, or just intranet?
For corporate LANs, sometimes setting up a Java Webstart page is the best solution; the customers always have access, they can make desktop shortcuts to the launcher to run just like a standard application, and you have absolute control for pushing updates.