Since cross-signing is no longer available, I was going to try this HLK method for the old OSes (WinVista/7/8/8.1, server 2003, 2008, 2008r2, etc.. basically all those in that generation). Does that mean I have to run against every os in every flavor (x64 / x86), that is a lot of OS installs and nowadays a pain since you can't get an updates. When first creating it you simply tested on the new OS that was going to be released and had years or two in between.
Related
I have a HP Pavilion dv6 which ran the x32 version of Windows 10, and so I wanted to install x64 OS. Also just a small side-note, the computer was set-up with Windows Insider. Anyway, I also have a Mac, which I created a USB boot drive with x64 Win10 (I originally used the Windows Media Creation software on my dv6), but whenever I tried to open the setup.exe file my dv6 would just say that the software is not compatible. That lead me to think that maybe Windows Insider was having an impact on the OS being slightly newer and not exactly compatible with the setup file... so I stopped Windows Insider updates and rollbacked to the latest Windows. But nope, the file still complained that it wasn't compatible. Skip past 2 days worth of me trying to create a boot drive and booting up my HP, whenever trying to boot up my dv6 with the image loaded on manually or by using Unetbootin, my dv6 would only complain that it's a Non-system disk or the USB drive doesn't contain an operating system.
Simply, I would just like to update my dv6 which now (sorry, I forgot to mention this earlier) after rollbacking now gets stuck in a loop of the green screen of death or blue screen of death and then "Recovering your computer" or something like that, from x32 to x64 os (and yes, I checked that it was capable of running x64 software).
Thanks,
Avoxel284
p.s. this is my first question, so sorry if I sound like some kind of noob or something...
p.s.s. i backed up my files, so all I need is to at least get it to some sort of OS.
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.
I am trying to install Sheridan controls (ActiveThreed 2.01) on Win7 64-bit, but evidently it is a 16-bit installer so it won't execute.
What would be the best way to get round this problem?
Can anyone comment on whether http://homepage3.nifty.com/takeda-toshiya/msdos/index.html would be helpful?
It took me months of googling to find a solution for this issue. You don't need to install a virtual environment running a 32-bit version of Windows to run a program with a 16-bit installer on 64-bit Windows. If the program itself is 32-bit, and just the installer is 16-bit, here's your answer.
There are ways to modify a 16-bit installation program to make it 32-bit so it will install on 64-bit Windows 7. I found the solution on this site:
http://www.reactos.org/forum/viewtopic.php?f=22&t=10988
In my case, the installation program was InstallShield 5.X. The issue was that the setup.exe program used by InstallShield 5.X is 16-bit. First I extracted the installation program contents (changed the extension from .exe to .zip, opened it and extracted). I then replaced the original 16-bit setup.exe, located in the disk1 folder, with InstallShield's 32-bit version of setup.exe (download this file from the site referenced in the above link). Then I just ran the new 32-bit setup.exe in disk1 to start the installation and my program installed and runs perfectly on 64-bit Windows.
You can also repackage this modified installation, so it can be distributed as an installation program, using a free program like Inno Setup 5.
You can't run 16-bit applications (or components) on 64-bit versions of Windows. That emulation layer no longer exists. The 64-bit versions already have to provide a compatibility layer for 32-bit applications.
Support for 16-bit had to be dropped eventually, even in a culture where backwards-compatibility is of sacred import. The transition to 64-bit seemed like as good a time as any. It's hard to imagine anyone out there in the wild that is still using 16-bit applications and seeking to upgrade to 64-bit OSes.
What would be the best way to get round this problem?
If the component itself is 16-bit, then using a virtual machine running a 32-bit version of Windows is your only real choice. Oracle's VirtualBox is free, and a perennial favorite.
If only the installer is 16-bit (and it installs a 32-bit component), then you might be able to use a program like 7-Zip to extract the contents of the installer and install them manually. Let's just say this "solution" is high-risk and you should have few, if any, expectations.
It's high time to upgrade away from 16-bit stuff, like Turbo C++ and Sheridan controls. I've yet to come across anything that the Sheridan controls can do that the built-in controls can't do and haven't been able to do since Windows 95.
I posted some information on the Infragistics forums for designer widgets that may help you for this. You can view the post with the following link:
http://forums.infragistics.com/forums/p/52530/320151.aspx#320151
Note that the registry keys would be different for the different product and you may need to install on a 32 bit machine to see what keys you need.
I am mostly posting this in case someone comes along and is not aware
that VB2005 and VB2008 have update utilities that convert older
VB versions to it's format. Especially since no one bothered to
point that fact out.
Points taken, but maintenance of this VB6 product is unavoidable. It would also be costly in man-hours to replace the Sheridan controls with native ones. Simply developing on a 32-bit machine would be a better alternative than doing that. I would like to install everything on Win7 64-bit ideally. – CJ7
Have you tried utilizing the code upgrade functionality of VB Express 2005+?
If not,
1. Make a copy of your code - folder and all.
2. Import the project into VB express 2005.
This will activate the update wizard.
3. Debug and get the app running.
4. Create a new installer utilizing MS free tool.
5. You now have a 32 bit application with a 32 bit installer.
Until you do this, you will never know how difficult or hard it
will be to update and modernize the program.
It is quite possible that the wizard will update the Sheridan controls
to the VB 2005 controls. Again, you will not know if it does
and how well it does it until you try it.
Alternatively, stick with the 32 Bit versions of Windows 7 and 8.
I have Windows 7 x64 and a program that will not run. However,
the program will run in Windows 7 32 bit as well as Windows 8 RC 32 bit.
Under Windows 8 RC 32, I was prompted to enable 16 bit emulation
which I did and the program rand quite fine afterwords.
I had 32-bit software with a 16-bit installer that I couldn't unzip. I solved it with otvdm which allows you to run windows 1.x, 2.x, 3 programs on win64. In fact, otvdmw allows you to select the program to run (otvdm is command-line).
16 bit installer will not work on windows 7 it's no longer supported by win 7 the most recent supported version of windows that can run 16 bit installer is vista 32-bit even vista 64-bit doesn't support 16-bit installer....
reference http://support.microsoft.com/kb/946765
Bottom line at the top: Get newer programs or get an older computer.
The solution is simple. It sucks but it's simple. For old programs keep an old computer up and running. Some times you just can't find the same game experience in the new games as the old ones. Sometimes there are programs that have no new counterparts that do the same thing. You basically have 2 choices at that point. On the bright side. Old computers can run $20 -$100 and that can buy you the whole system; monitor, tower, keyboard, mouse and speakers. If you have the patience to run old programs you should have the patience to find what you are looking for in want ads. I have 4 old computers running; 2 windows 98, 2 windows xp. The my wife and I each have win7 computers.