I see some comments in G-WAN website about discontinuing Windows version since Sep 9, 2009.
Now, I want to run the latest version of G-WAN web server in Windows, how can I do that?
Well, you'll have to convince Microsoft to update their issues which are slowing down G-WAN.
:) It's currently not very profitable to invest time in Windows when the bottlenecks are coming from the OS (from my understanding).
But, if you really want to run the latest version in Windows, you'll probably have to go down the virtualization route, and even then you'll still be depending on Linux to power it.
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.
We have a pretty huge HTML / JavaScript application written in a 15 year span that several programmers updated, edited and patched. We use this application on our computers (about 60 PCs) to teach languages online. The PCs that are used by our teachers are all Windows 8.1 (last update made in 2015), and the current IE version that's running the application is (it works only on IE):
Version: 11.0.9600.17937
Update version: 11.0.22
The decision to stop updating the computers was made due to the worry of compatibility issues. I'm taking over the position of the previous IT guy and I think it would be mandatory to update all machines with Windows 10 and the latest version of IE.
I would like to know your opinion and if there could be any compatibility issues between the IE11 version we are currently using and the latest version available on Windows 10.
I'm going to test myself the whole thing anyway.
Thank you for your help.
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.
When I run 'meteor update', it says that I have the latest version Meteor 0.8.3. When I specify the release using '--release 0.9.2.2', it says that the version is unknown.
What's going on here?
I tried reinstalling but got the exact same behavior.
Unfortunately, Meteor does not support Windows out of the box. That means that it has to be ported, which takes some time. So if you want the newest Meteor version as soon as it is released, you can either run a VM with Linux (for example, using Virtualbox) or install Linux alongside Windows on you computer (make sure to back up all data before, though!)
Or you can just wait becuase as saimeunt pointed out, Meteor will be ported to Windows soon.
From March 31, 2015, meteor is supported on Windows
https://www.meteor.com/install
I have had basic tests for meteor on a Windows7 PC.
But there the application crashed too often.
Before this, I tested meteor on PC running Windows8. There, crashes happened much less often and generally they were recovered when I shutdown and rebooted the meteor.
Is Meteor unstable on windows7?
Or is there any way to avoid this?
The version packaged to the MSI installer that can be found on win.meteor.com is not official. If you want a more stable, try the virtualized option I've described on the site. I've been using that for a month without issues.
Please could you be specific about what problems you are seeing, for example, what do you mean by 'crash'.
You can certainly raise issues on SO, but if they appear to be specific to the windows port, please raise a ticket at: https://github.com/sdarnell/meteor
The only difference between Win7 and Win8 meteor, is that the installer sets the Win7 compatibility mode for the node.exe executable on Windows 8.
There are also relatively few differences between the windows port of meteor and the official linux/mac release. So there is a possibility that the issue is either environmental (e.g. you have different things installed on the two machines), or it may even be a core issue that just happens to appear more often Win7 due to timing issues (there was a case of this in 0.6.3).