I have a graphics program that I use frequently. It requires IE5 which no long runs on newer computers. It's 32 bit. I have it installed on an older 32 bit computer and it's a pain having to switch back and forth. I might try Llnux on that computer along with Win10 to see how it works.
is the graphic programs publicly available ? would you give me the link. It is strange it requires IE5 !
to boot from usb on windows 10 , use this steps :
https://store.hp.com/us/en/tech-takes/how-to-boot-from-usb-drive-on-windows-10-pcsif you have a mac you know what to do.
It's the old MS PictureIt 9.0. It was part of the old MS Works. I use it to make calendars because it does some stuff that no other program I've tried can do.
IE5 only runs on 32 bit computers. A local print shop recommended that I try WinCalendar which is part of Office up through Office 2007. I found out that it's got the same problem. It won't run on a 64 bit computer so it's rapidly going obsolete, too.
That is not a true statement at all. It has absolutely nothing to do with 32 bit or 64. It’s the new Windows architecture, and outdated software.
But first, it’s helpful to understand what happens when you run an application under 64-bit Windows. Some applications and libraries (DLLs) are compiled in such a way that they can run either as native 64-bit or 32-bit mode. Other applications and DLLs, however, can only run as 32-bit.
Let’s say you have an application that easily runs as a 64-bit app under Windows 2008 R2 (which is a 64-bit OS). No problem, right? But what if that app makes a call to a Crystal Reports DLL that is compiled only as a 32-bit DLL? Trouble! That’s what happens! The application will not be able to find the DLL. As far as the app is concerned, the DLL doesn’t exist.
To understand why, we must understand how Windows separates 32 and 64-bit components. Windows x64 stores 32-bit DLLs in the Windows\SysWoW64 folder, while 64-bit DLLs go in the Windows\System32 folder. That seems backwards, doesn’t it? But it gets even more counter-intuitive. When a 32-bit mode application runs under Windows x64 and wants a DLL from “c:\windows\system32”, Windows will “lie” to the app and give it the DLL from C:\windows\syswow64!
The flipside of this redirection scheme is that 64-bit apps are affected as well. 64-bit applications cannot see or access the Windows\SysWoW64 folder. They can only see Windows\System32. If an application installer places a 32-bit DLL in Windows\SysWoW64, then later a 64-bit application tries to call that DLL, it will simply fail because, to the application, that DLL doesn’t exist.
The Solution
So what is the solution? We just have to get the 64-bit app to run as a 32-bit application. This will allow the app to see the 32-bit DLLs in the Windows\SysWoW64 folder and load them into its memory space. We will lose some of the benefits of 64-bit execution, but at least the app will work properly. And fortunately, we don’t have to get the vendor to send us a recompiled executable. We can force the app to run as a 32-bit app by changing the execution headers using the Microsoft CorFlags utility. All you have to do is install the Microsoft Windows SDK and grab CorFlags.exe from the Bin folder of the SDK program files directory.
Then all you have to do is run:
CorFlags /32BIT+ application.exe
where application.exe is the application you want to force to run as 32-bit. The next time you execute the application, Windows will see the new header and will execute it as a 32-bit application.
