Jul 19 2022 07:16 AM
Unified Binaries is like one binary that with proper runtime or framework integrated into Windows, can work in any architecture (ARM/x86). It's quite like Java or Python or .NET core, where a runtime for a specific architecture can run a same universal code for windows. I gave two different types of Unified Binaries:
1.for older binaries, There will be a runtime created that can run that can run non native (x86 on ARM or ARM on x86) windows binaries without any modification into the actual software.
2.Newer binaries will be compiled from scratch in a way that proper frameworks on windows can easily run it on any architecture. For .NET binaries you already have what to do. Just try to create a framework for C++ binaries
It's like Minecraft java, the underlying java part is the same but different launchers and C++ code for system communication. This method I assume can be designed in a way that the apps can think that they are running natively. Please also consider graphics
Jul 19 2022 08:17 AM
Jul 19 2022 07:46 PM
@ChinmoyDip2007Essentially what you're after, is managed code, which is an extremely powerful feature which is part of the CLR (.NET Framework.) Ironically, a lot of people who write software, even for mobile platforms, do not use managed code, despite the fact that it was widely available in most compiler toolchains around 2005-2006 or so. It's really strange, given almost every big problem is already solved by just using managed code, even performance issues in a cross-platform setting:
"Common Language Runtime (CLR) overview
...The runtime uses metadata to locate and load classes, lay out instances in memory, resolve method invocations, generate native code, enforce security, and set run-time context boundaries."
https://docs.microsoft.com/en-us/dotnet/standard/clr
https://en.wikipedia.org/wiki/Managed_code
Jul 19 2022 10:33 PM
Jul 19 2022 10:39 PM
Jul 20 2022 07:04 AM
Jul 20 2022 07:08 AM
Jul 20 2022 08:46 AM
Jul 20 2022 01:09 PM
@ChinmoyDip2007It would be a very good idea to brush up on how the IDE works, how compilers work, etc. You could select a different build option, make multiple releases based on the architecture, or you could just create a UWP App (basically a containerized version of the same thing) targeting as many architectures as possible. The problem with that is sometimes it makes it a much larger download, and not everyone would want that option. Some advantages are that it's more simple to deploy / update, if it's a very small application. On a mobile device, Xamarin and the UWP is really your only choice:
"App package architectures" -> https://docs.microsoft.com/en-us/windows/msix/package/device-architecture
What you were describing earlier was really just your frustration with object code / object files (which are part of an intermediate stage before linking.) Most people will just choose a different output format for the binaries / executables, and do multiple releases of the same thing, given C++ / C#, etc, are already high-level languages:
"Understand build configurations" -> https://docs.microsoft.com/en-us/visualstudio/ide/understanding-build-configurations
"In a C++ project, the linking step is performed after the compiler has compiled the source code into object files (*.obj). The linker (link.exe) combines the object files into a single executable file." -> https://docs.microsoft.com/en-us/cpp/build/reference/linking
"Cross-platform mobile development in Visual Studio" -> https://docs.microsoft.com/en-us/visualstudio/cross-platform/cross-platform-mobile-development-in-vi...
"The architecture options specify the architecture for code generation. Select the base hardware architecture you're working with to see /arch options for that target platform.
/arch (x86)
/arch (x64)
/arch (ARM)
/arch (ARM64)"
"/arch (Minimum CPU Architecture)" -> https://docs.microsoft.com/en-us/cpp/build/reference/arch-minimum-cpu-architecture