We are moving from CefSharp to WebView2. Because of certain requirements, we are thinking of going ahead with the fixed version where the updates can be controlled by us. Now, on Microsoft's official distribution page we have 3 options available - x86, x64 and ARM64. We have users who use different combinations of OS and CPU architecture. One example is 32 bit Windows 10 Pro running on a 64 bit Intel processor. Here is where I am confused. Which one to ship to agents depending on their combinations of OS and CPU architecture. Can anybody help here? Here are the combinations -
I have not tried out and hence may be a blunt question - can x86 distributable be a safe bait for all these combinations? If yes, then what are the trade-offs?
I think x86 distribution is safe. If 32-bit OS is running, the entire system acts as purely 32-bit. It's impossible to use any 64-bit piece of code, so 64-bit applications won't work. You can also check this thread: If you want to run 64-bit app on 32-bit OS, you have to install a VM or something. I think that's not what you want.
In conclusion, I think you should choose the WebView2 Fixed Version according to the OS version.
Related
Take for example a program downloaded from some website, the different options to pick from are the usual operating systems (Linux, Mac, Windows) but what about CPU architecture? The program is a binary executable. Does it just assume amd64? Or is the program compiled into all of the supported architectures and packaged together with a script on top that chooses the right one?
I'm only interested in C and would like to know how this is accomplished.
On further investigation, thanks to the lovely information provided by the individuals below, I came across Fat Binaries with support on both Mac and Linux. It doesn't seem as though windows supports it.
The Mac OS X binary format includes a mechanism for providing code for multiple architectures in the same file, and so a single Mac application can support 32 and 64 bit x86; in the recent past PowerPC support was possible too, although those are now obsolete. But for Windows and Linux, you generally need separate binaries for each CPU architecture (as comments have pointed out, it's possible to jury-rig something similar, although it's far from standard practice.) The default, and by far the most common, is amd64, but sometimes you'll still see separate downloads for 32-bit machines. The world used to be more interesting in this respect, but nowadays things are more standardized than ever.
We need to build a C library on various environment like (suse x86, suse itanium, solaris, HPUX, IBM AIX) with different compiler options(like compiler flags, 32bit or 64 bit, static or dyanamic, endianess etc). Currently we are building it on around 200 build machines. We are having an efficient makefile but still we need to login to various machines and doing FTP to take the code and then doing make and then again transferring libraries. Then we need to keep all 200 platform libs in one release machine.
Our intension is to reduce the effort of logging in to different machine manually for triggering build, what is the best way to do it?
One way to automate this by writing an expect script on one linux machine which will do login to all 200 machine, triggering build and taking back the libs and keep it on place.
Is there any other way is there which will takes less effort when compared to writing expect scripts for 200 builds? For example we need to build around 50 Vxworks platform, for that we are having tornado packages(cross compiler) in only one windows machine which will do all 50 platforms. For this we have written one click automation scripts(small script which doesnt require to login to 50 machine).
Similarly if cross compilers available for all *nix machine (suse, solaris, hpux, ibm aix, etc) compilers we can install all that in one machine(either linux or windows). Then we can write a script to automate all 200 builds in one machine without writing scripts for remote login or ftp.
Or is there any other easy way to handle builds in multiple *nix platforms?
Would Jenkins be a possibility for you?
It's becoming increasingly popular beyond Java projects (C/C++/C#). From what I understand, Jenkins would be a fit.
Take a look at the GNU AutoTools. Everybody knows how to use their output (the typical ./configure; make; make install dance), no strange requirements on the target, has extensive machinery to handle operating system vagaries. It's learning curve is quite steep, though.
I am developing a 64 bit application. Is it possible to run the 64 bit application on a 32 bit OS?
Please note that the question is generic and not specific to Windows OS. Infact the application in itself is portable across OS.
(We'll assuming your talking about AMD64 (== EM64T == x86_64) and x86 for 64-bit and 32-bit respectively)
You can run AMD64 code on x86 processors only by emulation (e.g. qemu), or some kinds of virtualisation (I believe VMWare might support 64bit guest OS on 32bit host OS on 64
bit capable CPU). However this means running a 64-bit OS as a guest on emulation or virtualisation I believe.
As you're developing the application, it shouldn't be too hard to develop both 32-bit and 64-bit builds of your code.
For Mac you can ship a single binary that has both types of code in it, or Mac OSX can run your 64-bit binary on a 32-bit kernel (only on a x86_64 capable processor though). For Windows and Linux, you'll either have to ship separate installers, or ship some smart installer, that selects the correct binaries at install time. For Linux there is a project for add the ability to run AMD64 code on x86 kernel on AMD64 processor - http://linuxpae64.sourceforge.net/ - but it doesn't look like it's got very far into the mainline kernel.
Is there a particular reason you only want to produce 64-bit binaries?
If it's to access extra memory, then the 32-bit OS wouldn't be able to give you extra memory anyway.
If it's to avoid have to test 2 different versions, then just produce the 32-bit version, it'll work on Windows AMD64, and most Linux AMD64 distributions without problems.
On windows, only using a virtual machine.
On OS X, 64Bit apps run natively (thanks Stephen)
The other way around is fine, bit I dont think you can run a 64bit app on a 32bit OS, you may be able to using a virtual machine or some kind of virtualisation.
There's an easier solution than trying to run a 64-bit program on a 32-bit OS (including executing through an emulated or virtual 64-bit platform on top of the 32-bit OS): recompile it for the 32-bit OS.
When you said it's portable across different OSes, did you also mean non-64-bit OSes? I could not call something portable without qualifying "only 64-bit" if that was the case, and I think many (maybe even most?) programmers also expect that qualification, at least currently.
it is possible using qemu in soft emulation mode
No.
See Microsoft FAQ:
The terms 32-bit and 64-bit refer to
the way a computer's processor (also
called a CPU), handles information.
The 64-bit version of Windows handles
large amounts of random access memory
(RAM) more effectively than a 32-bit
system. For more details, go to A
description of the differences between
32-bit versions of Windows Vista and
64-bit versions of Windows Vista
online.
Understand the difference between 32-bit and 64-bit and you will see why it's not possible.
See this (assuming you're running Windows):
If the program is specifically designed for the 64-bit version of Windows, it won't work on the 32-bit version of Windows. (However, most programs designed for the 32-bit version of Windows will work on the 64-bit version of Windows.)
Device drivers designed for the 64-bit version of Windows won't work on computers running a 32-bit version of Windows. To learn how to check for drivers, see Update a driver for hardware that isn't working properly or go to the device manufacturer's website.
On Windows, no. On OS X, yes. I don't know what the state of affairs is on Linux.
In fact, Snow Leopard boots into a 32-bit kernel, but compiles applications 64-bit by default, so this is quite common on OS X.
A 64 bit application does not run on a 32 bit processor period
A 64 bit application uses a 64 bit wide register. It just plain won't fit.
I have a WPF app that uses Flash10c.ocx developed on a 32 bit machine. I didn't have to register the ocx on my dev machine, I just installed the latest flash, added a reference and started coding. When testing on a 64 bit system I get ye old "Class not registered" which I think mean I need to regsvr the ocx. Is it Ok to just copy the 32 bit ocx (I'm pretty sure its 32 bit as its located in C:\Windows\System32\Macromed on the dev system) to a 64 bit system and register it?
Update: regsvr32 /i flash10c.ocx errors out with "The module flash10c.ocx las loaded but the call to DllRegisterServer failed with error code 0x80004005"
Update 2: I've given up on this and decided to run Flash on 32 bit systems only. If anyone has a better answer I'd like to hear it but I'm marking the current suggestion as answered to give due credit for the effort.
The reason it's not working for you is that your WPF application is running as 64-bit.
A .NET application is able to run as 32-bit or 64-bit; and the CLR is JITing your app to whatever architecture the application is running on - in this case 64-bit.
Except you now want your 64-bit application to load a 32-bit dll. This is not possible. A 64-bit process can only load 64-bit dlls. A 32-bit process can only load 32-bit dlls. No amount of fiddling with COM object registration will change this; it's not a question of missing registry entries.
Adobe Flash only comes as a 32-bit dll. Adobe does not now (and hopefully will never) have a 64-bit version.
In order for your WPF .NET application to load the 32-bit flash dll, it needs to be running as 32-bit process. There is a way, in Visual Studio's build configuration, to force your .NET application to only target x86, rather than Any CPU.
The choices of CPU targets are:
Any CPU
x86
x64
Itanium
Flash, for what it's worth, doesn't have an Itanium version, either.
See StackOverflow: Visual Studio “Any CPU” target for more discussion about target cpus.
May be the flash installer is meant to be only for 32 bit OS. Hence it did not install properly on a 64 bit machine. The error means that you will need to manually register the ocx but will it register successfully that's a totally different question.
Edit 1: here is Adobe's statement of support for 64-bit systems (there is none) (I assume you are using 64 bit browser on a 64 bit machine)
Edit 2: Another forum message about Flash on 64-bit Windows.
Next term, I'll need to write a basic operating system for Motorola 68K processor as part of a course lab material.
Is there a Linux emulator of a basic hardware setup with that processor? So my partners and I can debug quicker on our computers instead of physically restarting the board and stuff.
Is it possible to apply test-driven development technique to OS development? Code will be mostly assembly and C. What will be the main difficulties with trying to test-drive this? Any advice on how to do it?
I would recommend developing an operating system for the classic Amiga computers, which had different versions of the 68000 processor. Since the Amiga computer is a complete computer and is extremely well documented, I thought this would be a good exercise.
There is an emulator for it called UAE (and Win-UAE) which is very exact and
can be configured with different kinds of processors (68000 - 68060) and other capabilities. Normally, you would also need to acquire ROMs for it, but since you are developing an operating system yourself, this is not necessary.
Tools you will need is either Cygwin (for developing under Windows) or a Linux computer. Then you will need cross compilers. This includes both a C compiler and an assembler. Here is a template for creating a simple ROM which changes screen color and flicks the power LED. It will create a file 'kick.rom' which UAE then searches for in the current directory.
Reference on the 68000 instruction set can be found at the links below. Be aware that different assembler programs may use slightly different syntax and instruction set.
If you need to demo the operating system on real hardware, there are modern Amiga clones sold on Ebay and other places. Search for "Minimig".
Update:
Nowadays AROS also runs on UAE as well as physical Amigas.
Refs:
[UAE]
[WinUAE]
[Cygwin]
[Cross Compilers]
[68000 reference]
I would suggest QEMU for m68k emulation.
(The system emulator you want in QEMU is "Coldfire" - that's what Freescale calls the successor to the m68k architecture).
You certainly can tdd this project. First off decouple all accesses to the hardware with simple routine calls, e.g. getch() and printf, then you can provide simple mocks that provide test input and check output. You can then write well over 90% of the project on a PC using gcc, msdev or xcode. Once you have got some confidence in the decoupling routines you will need very little access to the hardware, and only then to occasionally check that your mocks are acting as you expect.
Keep to C until you find a particular bottle neck, and only then resort to assembler.
There are a few new projects that use hardware simulated 68000 cpus, the C-One project, the Minimig (Mini Amiga) project and the Natami (Native Amiga) project - they are new 68k compatible Amiga systems.
C One, reconfigurable computer, Minimig, in development, prototypes done: FPGA Arcade and Natami.
The Easy68k http://www.easy68k.com simulator might help you.
The uClinux project started on a m68k board. They may have the tools you need...