Has anybody tried and succeeded with installing flutter on win x86?
(no VM of course)
My question is not about what Google SAYs, but why do YOU think it is possible or not possible. I do not see anything in the source at github that may prevent it from running on win x86 apart that google does not want to provide support for x86, because it is not a priority.
If you think it is not possible, can you please provide some idea why before saying No or voting down
====BACKGROUND====
prerequisites for the flutter sdk on windows are:
dart 2.0
PowerShell 5.0 or newer
Git for Windows
inside there are also some java and libcurl executables
all of the above exist in win x86 versions
plus the rest seems to be just dart source code.
I run flutter on Ubuntu.
I have an older laptop with win 7 x86 pro which I do not want to upgrade to x64
I tried to use x64 win installation
replacing dart 2.0 x64->x86
and then using flutter doctor to update.
(flutter uses dart pub with "update" function changed to "upgrade", but this can be fixed)
the update using flutter doctor in fact runs just to the point of updating flutter_tool
then trying to update some flutter_tool related packages it comes up with an ERROR:
cannot resolve the library URL
The Windows installation page says:
To install and run Flutter, your development environment must meet
these minimum requirements:
Operating Systems: Windows 7 SP1 or later (64-bit)
And there is a recent comment (20 Aug 2018) from one of the Flutter developers that also states:
We don't have any plans to support 32-bit Windows. That said, if
anyone is willing to send pull requests to get Flutter running on
32-bit Windows, we'd gladly review the PRs.
A further response from the Flutter devs outlines some of the reasons why this is the case:
Someone would need to author 32-bit build rules in the
engine/buildroot repos to build a 32-bit SDK -- specifically the
Dart VM and gen_snapshot. Ideally, the rules would also emit the
target architecture Android artifacts as well.
The design of gen_snapshot (our AOT compiler) assumes identical host
and target architecture bitness. Only a 64-bit build of gen_snapshot
can output arm64 target binaries. Fixing this would involve a
significant amount of work.
Related
Are Flutter 2.2.3 and Android Studio Arctic Fox latest stable version (2020.3.1 patch1) optimized for Windows 11?
Is installing these two on the preview version of Windows 11 a problem?
On the Android Studio Website the following Windows operating systems are listed as System requirements:
64-bit Microsoft® Windows® 8/10
So technically this would mean you're outside of the system requirements and Android Studio is likely not optimized for Windows 11.
Dart has pretty much the same situation, listing only Windows 10 as supported.
From my personal experience, everything I've used in Windows 11 has worked the exact same way as it would have in 10, but there's always the possibility some issues will arise with unsupported software so staying within supported versions is always the better option if you don't want to deal with problems.
In short: It's not supported, you may run into issues, use it at your own risk. If you want to be safe, use it on Windows 10 until Windows 11 starts being supported by both tools and upgrade then.
I'm trying to build a windows application. But I'm running to the below error. I tried to download the version 10.0.18362.0 and rebuild the solution, but still runs into the same error.
"DEP3321: To deploy this application, your deployment target should be running Windows Universal Runtime version 10.0.18362.0 or higher. You currently are running version 10.0.17763.1397. Please update your OS, or change your deployment target to a device with the appropriate version."
Appreciate any suggestions on how to proceed.
Note: I followed other similar questions to change the target and minimum version. But still runs into the same error.
Thanks
According to the error message, this is because your current system version is lower than the minimum version required by the application.
The safer way is to upgrade the system. The current version of your system is 17763 (1809), you need to upgrade to at least 18362 (1903).
Here is the download address of the upgrade tool: Download Windows 10.
Another way is to reduce the minimum version requirements of the application.
Right-click the UWP application project, select Properties , and change the Min version to a lower version (such as 17763).
If the entire solution contains projects other than UWP application projects (such as some class libraries), the minimum version also needs to be adjusted.
This is not a safe method. Because some APIs used by the application may only be provided in versions 18362 and above, the version cannot be lowered in this case.
I've been trying to figure out how to run some code I got off the internet to understand how to make a proper directX 12 application and when I run it I get the error message below, pointing to the code displayed in the second image down.
I've ran Windows Update several times over and installed the DirectX End-User Runtime Installer and I still get this message. What do I need to do to solve this problem? I'm stumped.
The DirectX "Debug Layers" for Windows 10 are installed as an 'optional feature' in your Windows installation. Go to the Settings panel, under System, Apps & features, Manage optional Features, Add a feature, and then look for "Graphics Tools".
The "DirectX End-User Runtime Installer" has not actually changed the version of DirectX installed on any version of Windows since ~2002. It has also never installed the debug runtime. The legacy DirectX SDK only includes an old Windows 7 RTM version of the Debug Layer for DirectX 11.0. On Windows 7 with the KB2670838 installed or Windows 8.x, you need to install the latest Windows SDK to get the debug layers installed.
For more information, see Direct3D SDK Debug Layer Tricks and Not So Direct Setup.
Short version:
When I moved to Win7, I manually removed the MDAC 2.7 lines from my .ISM module, built it, and installed my software. It seems to work. Can I trust it?
Longer version:
We have just gone from XP to Windows 7. The software we deliver is C# (.NET 4 framework), targeting XP and Windows 7. It contains a few older COM modules, one of which is written in VB6. (Yes, I would love to rewrite this in a modern technology, but that's not an option at this point.)
I use InstallShield 2010 to build the installer for this package. Building this installer on XP worked with no problems. When I try on Windows 7, it wants MDAC 2.7 as a prerequisite merge module. Microsoft doesn't allow you to download 2.7 anymore, and I'm not going to get it from "Sharewarez R'us" sites.
The error InstallShield gave me when it couldn't find the merge module was: File not found. An error occured merging Module 'MDAC27ENU...'
From what I've read on the web, Windows 7 has the latest-greatest MDAC (now renamed WDAC) already installed. On a whim, I manually deleted the MDAC dependencies from the .ISM, built and installed, and my software seemed to run just fine.
What I think is happening is Win7 is noticing that something in VB6 is using MDAC and the OS is supplying the latest-greatest and it just works. I no longer need the merge module because Windows 7 has WDAC built in. (Can it really be that simple?)
My main question is: can I trust it?
My secondary question is: What about XP deployments? They will still need MDAC 2.7... Does that indicate I can't build on Windows 7 to target XP if I require MDAC 2.7? Please point me in the right direction. Thanks.
You need a comprehensive review (dependency analysis) of your installer. The VB6 runtime and MDAC/WDAC components are all built into windows these days. This is also the case with Windows XP and the latest service pack.
Either your ISM is referencing the MDAC merge module or it's referencing another merge module that has a dependency on the MDAC merge module. Hence why I suggest a complete review.
Without looking at your application I can't give you a 100% answer but odds are that if you implement a setup condition (launch condition) to check for XP latest service pack or newer that you will likely work without installing a bunch of stuff you don't need to be installing.
I am upgrading my Windows Mobile 5 project to a Windows Mobile 6 project.
The first step (at least so it seems to me) is to get the Windows Mobile 6 SDK installed.
When I went searching for this I found the following installs that both seemed to fit what I was looking for:
Windows Mobile 6 Professional SDK Refresh.msi
Windows Mobile 6.5 Professional Developer Tookit (USA).msi
So, the question is, do I need these both? and if so, what order do I install them in? and is there any other installers/steps I am missing?
It depends on what you're targeting. There are loads of SDKs, but generally what they bring to the table are emulators and SDK-specific stuff (like additions to the Microsoft.WindowsMobile namespace). Otherwise they really don't do a whole lot. For example you can continue to use just the PPC 2003 SDK to write and deploy apps on WinMo 6.5, you'll just be missing availability of the stuff that was added to be 6.5-specific.
Persoanlly I'd recommend installing the 6.5 Pro (and maybe standard too) SDKs and foregoing the 6.0 SDK unless you need to do emulator testing for something like a 6.0 or 6.1 device.