MiceWine – run Windows applications and games on Android smartphones
github.com
github.com
Now the community is split into multiple forks of version 7.1 in order to add new features & fixes, like Winlator Frost and coffincolors' fork. It's hampering progress and makes the scene very confusing to navigate, so we're rooting for a neater alternative, whether that's MiceWine or whatever else is coming up.
BTW if you liked X-Com: UFO Defense and want a blast from the past, try out The X-Com Files[1]. It runs on the Android build of OpenXcom[2], and it's not terribly difficult to set it up to sync Savegames between Android and your desktop.
You can't run amd64 without something like Box64 because Wine is not an emulator, so it doesn't interpret or rewrite the instructions to aarch64.
You can use Box64 on other ISAs if you implement the necessary translation code. I believe this is what's being done to run games on RISC-V, but I'm not 100% sure. Good ol' qemu-static would also do the job if Box64 isn't compatible (yet), but that's running the entire application in a foreign architecture so the overhead would be a lot more significant.
If what you describe is being done, it's being done by Box64. I don't know enough about aarch64 to know what ARM64X and ARM64EC do, though. I can find [a Github comment](https://github.com/ptitSeb/box64/pull/858#issuecomment-16057...) where one of the authors states that the goal is to implement ARM64EC, but I wouldn't know what the status is on that.
Fresh account, comment is just a URL.
The app experience reminds me of early Android tablet days where some apps just don't know what to do with a different orientation or window size that isn't constrained by the screen.
If you have apps that work well on phone and tablet or web based apps you're probably golden.
In German there is "Mäusewein" which translates to mice wine. It's when you have bad microbes while fermenting wine and the product tastes a bit like mouse urine.
Not sure if that had anything to do with the origin of the emulator's name though.
Then the GitHub ToS applies: https://docs.github.com/en/site-policy/github-terms/github-t...
>By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories
2. GitHub already does this. https://i.imgur.com/yAfwWGs.png
I'm not sure if unlicense/public domain would be a better default though. At the very least, that Github prompt should explicitly state with a warning what it means when you select "None" as the license. I think most people don't realize or know what it means for others who want to look at or use the project.
It seems like a pretty easy thing to do, and I don't know why its not common / not a thing on common Android phones.
https://m.youtube.com/watch?v=UnJ3amzJM94
Maybe the author is not aware of these? How about opening an issue?
Excuse me? SAF is awful and source of constant complaints from developers.
They can also request the user for a specific folder to get read/write permissions for (rather than the entire shared storage space).
Just requesting full access to the entire shared storage is a lot easier to implement, but it's also not great for privacy and security. Google is trying to crack down on these permissions in the Play Store for this reason.
Several apps have been caught extracting location history data from pictures stored in the camera directories already, so it's not a theoretical threat. Unfortunately, app developers have been reluctant to implement the (much better) specific file picker introduced in Android 4.4, but now they're being forced to if the want Google Play access in the future.
The scoped storage API has some downsides, though, such as reduced performance. Not really a problem if all you want to do is upload a picture or save a document, but when you're running executables from there you may run into a wall. This can be circumvented by copying the files to the app's private data directory, but people may want to use the selected folder to copy output back to Android, and a copy action obviously doubles the space required at least temporarily.
That being said, I believe applications shouldn't refuse to work entirely without full access to every file on the shared storage space. They can ask the user what they want to do if the storage permission is denied rather than refuse to work.
Extra unfortunate is that the new file picker Google introduced a few months ago for media selection is absolutely terrible in my opinion (no directory support, just a flat list of images), but some other phone brands offer file pickers of their own.
While I have my problems with the current state of things in Android, I think the new mechanism is better as a whole than the old mechanism where every flashlight app could upload your nudes to the cloud without you knowing. Had the Android developer landscape jumped ship to these APIs earlier, I'm sure the kinks would've been worked out years ago.
The unfortunate lesson Google seems to have learned is that giving developers the option to use safer, privacy-friendly APIs that put the user in control doesn't work, and forcefully disabling old APIs and forcing developers to update their apps to comply does. Hardly a surprise, to be honest, given Android's ecosystem is still full of shovelware and third-party "ad libraries" filled with adware and stalkerware (often making use of an app's legitimate permissions for nefarious means). I'd like Google to crack down on these, at least on their store, but then I'm sure we'd see weeks of HN threads about how Google broke the latest and greatest app by altering the API.
Should remove all books above a grade 10 reading level, since most people can barely read?
Is it more difficult to get non-gaming apps working?
I think its opt-in by the app developer, Authy (shitty company, I'm aware) does not work on Bluestacks. That's a pain, because I've used Bluestacks to migrate auth codes before.