Very Silly question. can someone quickly share me the Azure download link for 32-bit OS version from microsoft?
Regards,
Viswa V.
https://www.microsoft.com/en-us/download/details.aspx?id=48178
But instead of manually downloading, it is recommended you use the automated one-click install provided by the Web Platform Installer (x86 version here).
I don't think you will find that. I don't know if SDK exists, however Azure doesn't run 32 bit operating systems anyway for obvious reasons. Only 64bit operating systems are supported.
Related
I have searched high and low for installers to customize after creating my applications (small, medium, and much bigger) in size. Yes, portable apps great but most people just want to install and also have it just update when updates are available and install and restart the next time or at least warn the user to save the work before the Application can reopen.
Yes, I have looked at NSIS and other installers, but they are merely for windows and not for both windows and Linux. Some of these installer projects have been discontinued. Most people who use Linux don't like to always build from the source.
I was wondering how I can create a POSIX compliant installer that my software can install on both Windows and Linux. What are the steps involved? I assume most or all installers use C++ to do all of the grunt work. I am interested in creating my own to fully understand C++ and how it works. This why I really need to know how an installer is made. Any helpful advice is welcomed.
Thanks in advance.
"Mainstream": A shared packaging format seems elusive. However, there are a few multi-platform deployment tools available. Installsite.org has a list towards the bottom here. I guess the two most commonly used tools are (both are commercial):
Advanced Installer for Java / Advanced Installer Enterprise (Windows and Mac, no Linux)
Flexera InstallAnywhere (Windows, Mac, Linux)
From this answer:
We've got a .NET Core app that was hosted in Azure Service Fabric. Now we are moving it to Linux-based Docker containers.
We need to be able to create 7zip archives for an external service (one of those fancy "drop your files here via ftp" interfaces which requires 7zip archives).
Until now we could use a CLI wrapper ported from .NET Framework to .NET Core. But that does no longer work once we switch to a Linux environment.
We can't change the external service (because it is not ours) and we don't want to use Windows-based Docker containers.
There is a large number of 7zip NuGet packages for .NET Framework. Very few for .NET Core (mostly outdated and no longer maintained). And none I could find for .NET Core on Linux.
Do you have any suggestions on how we could solve that issue?
UPDATE: I found one similar question among the open issues of the SevenZipSharp project. Sadly there is no solution included.
UPDATE 2: Unfortunately we can't use an alternative implementation of the LZMA algorithm. Our 3rd party requires archives in the .7z format :-(
This is not an answer as it doesn't really provide a solution to the question, but it does address why it unlikely there will come an updated 7Zip library for Linux and address the problem with a good LZMA OS-cross-platform compression engine. So it should be seen as a long Comment, I hope it's okay.
It seems 7Zip is not maintained on Linux at all, current library is rather old, and I don't trust it's compatibility with the current and newer Windows 7Zip versions, so in my view 7Zip on Linux is a no-go. It's my understanding that Igor Pavlov (creator and maintainer of Zip) only target Windows. And he's not the creator of the current and old Linux 7Zip library.
A LZMA compression engine with both Linux and Windows support is LZip (.lz).
The latest library (zlib) is 1.11 and in July 2019 I sent a request to Domani Hannes to compile a new Windows version and he was to kind to reply with a download link and the following message:
I just now built plzip-1.8 with lzlib-1.11 and mingw-w64-winpthreads-v6.0.0.
There are no longer modifications necessary to be able to compile for Windows, so it's pretty straightforward.
I guess it mean it's easy to compile newer Windows versions in the future too.
Download link to this binary: plzip_zlib_1.11.exe.
I haven't have time to test it thoroughly yet for my own project, so if anyone go down this path please share your experiences (with a risk of hijacking this thread, so maybe not :-P).
Can someone tell me if Origen is supported on the Windows platform?
If it is, is there a guide for the installation process?
If not, are there any plans to support it in the future.
Thanks,
Priyavadan
Yes Origen is supported on Windows, but at present most of the user base is on Linux.
There is a Windows installation guide here, though it has a tendency to go out of date due to it being used less often than its Linux counterpart.
Please raise a ticket on Github if you end up here because of it not working: https://github.com/Origen-SDK/origen/issues
I want to know how we can check the bitness (32 or 64 bit) of any WIM file programmatically?
I am using VC++ for development, i did enough googling but didn't get anything much about WIM file bitness.
DISM.EXE is your friend. Windows 8 or later...it has all sorts of information. Take a look at this link. One thing you can probably do is enumerate drivers. Look for the existence of x64 (amd64) in the architecture column for a coarse clue.
You could mount the wim (dism does that, too)...and then interrogate the registry. That's going to be definitive, but more of a pita and more time consuming. There's reg.exe...that will let you load a "foreign" registry hive - and you can load a registry hive from a mounted .wim. By all means, don't forget to unload the hive...or you will make the .wim very difficult to unmount.
If need be, you can run newer versions of DISM on older boxes (to get all this cool new functionality). There are architecture-specific versions of DSIM in the Windows ADK.
Anyone have experience with OPOS? I can't get my app to recognize the LDNs for the devices running on a 64 bit machine.
I've got down to the point where I know that the OleforRetail stuff is now under Wow6432Node in the Registry. I suspect the common controls can't find the LDN because of this. Is there any kind of workaround?
Failing that, is there a centralized OPOS development forum somewhere?
BTW: I work with the common controls supplied by Monroe Consulting.
Thanks!
What are you using to develop your application?
If you are using .NET you need to set it to be compiled as a 32-bit version.
Platform target: x86 on the c# project settings.
If a program is 32 bit or 64 bit decides where in the registry it looks for values.
All the OPOS com objects are 32-bit, so if you use a 64-bit program it will not find any information about them.
The biggest problem that I had is that the LDNs weren't being found by my app. Well it turns out that you have to run the OPOS driver configuration software as administrator to get it to manipulate the 32 bit section of the registry properly. The LDNs just weren't being written in the right place in the registry so my app couldn't find them.