How to build the portable version?
How to build the portable version?
Hi,
I have been given the responsibility in my company of getting a couple of our Windows apps working on macOS, so I am obviously trying to use Wine to achieve this. I am also using Wine-Bundler to create proper self-contained macOS apps.
All of that is fine but there have been some issues in the apps which mean I need to build Wine myself. If you are interested what these issues are, the first issue is that our main Windows product is very complex and CPU intensive. Running on v4.0 is fine for this but on v5.x it crashes all over the place. So, I am continuing with v4.0. The next issue is that running v4.0 on Catalina only shows some folders and files in all the file dialogs. Simply rebuilding the source for v4.0 fixes this problem for me. The last issue is with another of our Windows products which needs ScriptGetCMap() from gdi32.dll, which is not present. Someone submitted a patch for this several months ago but it has never made it in to any release (yet). So I need to apply this patch.
So, I have successfully got Wine building on macOS. And running the build from the source tree works great. But then transferring this build to the macOS app results in being unable to find "ntdll.dll.so". See below.
wine: failed to initialize: dlopen(/usr/local/lib64/wine/ntdll.dll.so, 258): image not found
When I have updated the macOS app created by Wine-Bundler I have simply dropped in the newer Wine binaries and the entire lib64 directory. Just doing this, and nothing else, produces the above error. So, all scripts in the macOS app are the same as before. With the downloaded portable v4.0 it launches fine but with the new build it fails as above.
So, I am thinking that I need to build Wine to be the portable version. But I cannot find out how to do this. I see there are portable versions available for download, so how do you make these releases?
Thanks.
I have been given the responsibility in my company of getting a couple of our Windows apps working on macOS, so I am obviously trying to use Wine to achieve this. I am also using Wine-Bundler to create proper self-contained macOS apps.
All of that is fine but there have been some issues in the apps which mean I need to build Wine myself. If you are interested what these issues are, the first issue is that our main Windows product is very complex and CPU intensive. Running on v4.0 is fine for this but on v5.x it crashes all over the place. So, I am continuing with v4.0. The next issue is that running v4.0 on Catalina only shows some folders and files in all the file dialogs. Simply rebuilding the source for v4.0 fixes this problem for me. The last issue is with another of our Windows products which needs ScriptGetCMap() from gdi32.dll, which is not present. Someone submitted a patch for this several months ago but it has never made it in to any release (yet). So I need to apply this patch.
So, I have successfully got Wine building on macOS. And running the build from the source tree works great. But then transferring this build to the macOS app results in being unable to find "ntdll.dll.so". See below.
wine: failed to initialize: dlopen(/usr/local/lib64/wine/ntdll.dll.so, 258): image not found
When I have updated the macOS app created by Wine-Bundler I have simply dropped in the newer Wine binaries and the entire lib64 directory. Just doing this, and nothing else, produces the above error. So, all scripts in the macOS app are the same as before. With the downloaded portable v4.0 it launches fine but with the new build it fails as above.
So, I am thinking that I need to build Wine to be the portable version. But I cannot find out how to do this. I see there are portable versions available for download, so how do you make these releases?
Thanks.
Re: How to build the portable version?
Wine-Bundler doesn't handle the needed dylibs or setting needed exports so it's not really self contained.
As you've managed to compile wine from source you really should make a bugzilla for the CPU issue with your application(s) else it won't get fixed.adamAC wrote: ↑Tue Jun 23, 2020 2:52 am All of that is fine but there have been some issues in the apps which mean I need to build Wine myself. If you are interested what these issues are, the first issue is that our main Windows product is very complex and CPU intensive. Running on v4.0 is fine for this but on v5.x it crashes all over the place. So, I am continuing with v4.0. The next issue is that running v4.0 on Catalina only shows some folders and files in all the file dialogs. Simply rebuilding the source for v4.0 fixes this problem for me. The last issue is with another of our Windows products which needs ScriptGetCMap() from gdi32.dll, which is not present. Someone submitted a patch for this several months ago but it has never made it in to any release (yet). So I need to apply this patch.
The files not showing up is the new security on Catalina, wine64 should be asking for permission to access some resources
That error is Linker related I believe, I have a few Winehq esk bundles uploaded https://github.com/Gcenx/macOS_Wine_builds maybe test Wine-Devel-5.11.adamAC wrote: ↑Tue Jun 23, 2020 2:52 am So, I have successfully got Wine building on macOS. And running the build from the source tree works great. But then transferring this build to the macOS app results in being unable to find "ntdll.dll.so". See below.
wine: failed to initialize: dlopen(/usr/local/lib64/wine/ntdll.dll.so, 258): image not found
When I have updated the macOS app created by Wine-Bundler I have simply dropped in the newer Wine binaries and the entire lib64 directory. Just doing this, and nothing else, produces the above error. So, all scripts in the macOS app are the same as before. With the downloaded portable v4.0 it launches fine but with the new build it fails as above.
Grab the files from /Contents/Resources/wine , I say Wine-Devel-5.11 as I split the dylibs so /lib only contains 32Bit and /lib64 only contains 64Bit
The now deprecated Winehq macOS releases were cross-compiled using Debian stretch, using a copy of the 10.8 SDK and a patched version of Clang-3.4, some of the scripts were uploaded to the old wine-staging teams under wine-packing. But I wouldn't recommend it considering it's vastly outdated
Re: How to build the portable version?
Many thanks for your reply.
I have tried your release from GitHub but they all keel over with the CPU issue.
How are you building these releases?
Do you have a v4.0.4 release you have built as the one on WineHQ doesn't work?
I have tried your release from GitHub but they all keel over with the CPU issue.
How are you building these releases?
Do you have a v4.0.4 release you have built as the one on WineHQ doesn't work?
Re: How to build the portable version?
Then it’s definite a wine-5.x issue, I’m assuming you didn’t get the other issue as you never mentioned it?
The releases on GitHub were all built on macOS Mojave using CodeWeavers LLVM/Clang8 with Xcode11.3.1 & a modified 10.14SDK that allows an i386 target.
The build environment used macports in combination with https://github.com/Gcenx/macports-wine
Some macports-ports packages are overrode ether due to upstream issues or the package being incompatible, the MoltenVK/VulkanSDK packages use the prebuilt LunarG package over attempting to build from source with its ever increasing Xcode requirement.
For macOS Mojave the attached patch allows ports to be installed as universal by using a 10.13SDK you need to provide this.
Wine(64) is compiled using macports dependencies with any needed compiler flags.
Configure options I used are listed on GitHub.
After being installed into destroot hardcoded rpaths corrected to relative paths
I haven’t built Wine-4.0.4 as it had came out after 5.0 but I could have my building created it.
Re: How to build the portable version?
Many thanks Gcenx.
I was on holiday yesterday so I will pick this up today. I was building Wine on Catalina but I do have another Mac with Mojave so can use that to try to build it. Yes, I could downgrade Catalina but I have 2 Macs specifically for testing/dev on purpose where one is Catalina and the other is pre-Catalina.
From your instructions/guidance, it looks like the crucial line is "After being installed into destroot hardcoded rpaths corrected to relative paths", which will solve my previous problem.
I was on holiday yesterday so I will pick this up today. I was building Wine on Catalina but I do have another Mac with Mojave so can use that to try to build it. Yes, I could downgrade Catalina but I have 2 Macs specifically for testing/dev on purpose where one is Catalina and the other is pre-Catalina.
From your instructions/guidance, it looks like the crucial line is "After being installed into destroot hardcoded rpaths corrected to relative paths", which will solve my previous problem.
Are you referring to the file dialogs being blank or only certain files and folders being shown?
Re: How to build the portable version?
If you only need wine64 then there is no need to build on Mojave over Catalina, if you also need wine then building on Mojave would be simpler.
The dialogs being blank with winehq/xquartz based builds is related to the version of libpng15 being used, I'd rebuilt it to bundle within my Wineskin fork and no longer have these issues with Winehq releases.
Certain files/folder not being shown is the change in security on macOS Catalina, multiple locations now require permissions to access the following locations;
- Desktop
- Downloads
- Documents
- Music
- Pictures
- Network Drives
You need to use install_name_tool to change the hardcoded path from /where/the/libs/are/ to rpath/libary_name.dylib, this combined with a correctly configure rpath during compilation will make a more portable build.
The alternative is configuring DYLD_FALLBACK_LIBRARY_PATH to also include wine/lib(64)
adamAC
Hi Gcenx,
Thank you for all your help so far. You have been a star.
I have now managed to successfully build many different versions of Wine on a Mac, and produce "portable" builds. I have then used these builds to successfully create Mac apps.
I am now getting down to the nitty-gritty issues.
The first big issue is that in all file dialogs (open, save, & folder selection), some folders and most files DON'T show when running on Catalina. On Mojave, all works great. You have mentioned before that you believe this is down to a change in the security on Catalina. However, if I simply run "notepad.exe" with the same Wine binary in my Mac app I can see all folders and files. So the problem is only in our Windows app running on Catalina. We are not doing anything special in these dialogs. They work perfectly fine on Mojave but not on Catalina. As these file dialogs work fine in Notepad I don't believe it can be a security issue as you would see the same in both. Do you have any other ideas why this may be?
Thanks.
Thank you for all your help so far. You have been a star.
I have now managed to successfully build many different versions of Wine on a Mac, and produce "portable" builds. I have then used these builds to successfully create Mac apps.
I am now getting down to the nitty-gritty issues.
The first big issue is that in all file dialogs (open, save, & folder selection), some folders and most files DON'T show when running on Catalina. On Mojave, all works great. You have mentioned before that you believe this is down to a change in the security on Catalina. However, if I simply run "notepad.exe" with the same Wine binary in my Mac app I can see all folders and files. So the problem is only in our Windows app running on Catalina. We are not doing anything special in these dialogs. They work perfectly fine on Mojave but not on Catalina. As these file dialogs work fine in Notepad I don't believe it can be a security issue as you would see the same in both. Do you have any other ideas why this may be?
Thanks.
Re: adamAC
That's good to hear
It's due to the new permissions within macOS Catalina, you now need permission just to view the locations I mentioned about let alone write to them. macOS Mojave you could view any location but write permissions was restricted to what your user could do without using sudo.adamAC wrote: ↑Fri Jul 03, 2020 8:46 am I am now getting down to the nitty-gritty issues.
The first big issue is that in all file dialogs (open, save, & folder selection), some folders and most files DON'T show when running on Catalina. On Mojave, all works great. You have mentioned before that you believe this is down to a change in the security on Catalina. However, if I simply run "notepad.exe" with the same Wine binary in my Mac app I can see all folders and files. So the problem is only in our Windows app running on Catalina. We are not doing anything special in these dialogs. They work perfectly fine on Mojave but not on Catalina. As these file dialogs work fine in Notepad I don't believe it can be a security issue as you would see the same in both. Do you have any other ideas why this may be?
When launching wine(64/32on64) let's say via Terminal the resulting processes will inherit its permissions, if instead wine(64/32on64) is instead launched from within an app bundle that app bundle will require these permissions.
The other annocance that i've encountered was the tccd database can be corrupted causing the app to no request the required the required permissions, also if the code-signature is invalid permission prompts also won't happen.
An interesting effect of the inheritance system is each Port I've created using my Wineskin fork each having its own unique BundleID requires permissions per BundleID, however when launched using PortingKit (a frontend that does all configuration based on scripts that uses my Wineskin fork as the wine backend on macOS) instead the Ports inherited the permissions it has been granted.
Re: How to build the portable version?
I forgot to mention that if I build Wine on Catalina then I can see all the files and folders. But if I build it on Mojave then I can't.
I am trying to get to the point of only creating a single build that will work on both OSes (i.e. Catalina and pre-Catalina) but the Catalina build won't work correctly on Mojave. Building it on Mojave will work on Catalina except for this folder and files problem.
So, on Catalina, I have given my Mac app "Full Disk Access", and the same files and folders are still not showing.
My Mac app never requests permission to access anything. Neither does Wine when I execute that from a terminal with my Windows app.
So, I guess the tccd database could be corrupt as you say, whatever that is.
I am trying to get to the point of only creating a single build that will work on both OSes (i.e. Catalina and pre-Catalina) but the Catalina build won't work correctly on Mojave. Building it on Mojave will work on Catalina except for this folder and files problem.
So, on Catalina, I have given my Mac app "Full Disk Access", and the same files and folders are still not showing.
My Mac app never requests permission to access anything. Neither does Wine when I execute that from a terminal with my Windows app.
So, I guess the tccd database could be corrupt as you say, whatever that is.
Re: How to build the portable version?
This could be due to the quarantine/translocation flag(s) when moving between systems.adamAC wrote: ↑Mon Jul 06, 2020 5:24 am I forgot to mention that if I build Wine on Catalina then I can see all the files and folders. But if I build it on Mojave then I can't.
I am trying to get to the point of only creating a single build that will work on both OSes (i.e. Catalina and pre-Catalina) but the Catalina build won't work correctly on Mojave. Building it on Mojave will work on Catalina except for this folder and files problem.
So, on Catalina, I have given my Mac app "Full Disk Access", and the same files and folders are still not showing.
When wine64 is launched via Terminal it would be the one requesting permissions not wine64, when and app bundle launches wine64 the app bundle Name/BundleID would be what requests the permissions.
The tccd database contain permissions like access to web camera/microphone/full disk access/etc, here is a python script I forked and removed the location reset since that requires sudo https://gist.github.com/Gcenx/668befa14 ... 589b983f2e
You could build wine64 one time on Catalina by using the following flag -mmacosx-version-min={version_here} for example I'm using -mmacosx-version-min=10.9, just a little warning if your plan is to bundle the dylibs those also need to support the same -mmacosx-version-min= configuration or not contain one.
If your plan is to code-sign and notarize this app you can't use the dylibs from XQuartz as those were not built using a new enough SDK, the lowest SDK allowed to be used currently is the 10.9 SDK
Re: How to build the portable version?
Thanks again for all your help and guidance.
I decided to re-install Catalina as I had numerous version of Wine installed and it got quite messy. Also, this will be a good test for end-user testing as this Mac had all the dev tools installed whereas after the re-install it won't.
So, after the re-install I copied my Mac app to Applications and ran it. It died almost instantly. Running it from a terminal produces this error in all the output:
I tried building Wine using "--without-freetype", which built fine but then Wine failed to load my Windows app during initialisation (of Wine). It errored on something else to do with fonts, and saying there was a division by zero.
Do you have any advice on how to overcome this latest issue? Then I can get back to trying your other advice.
I decided to re-install Catalina as I had numerous version of Wine installed and it got quite messy. Also, this will be a good test for end-user testing as this Mac had all the dev tools installed whereas after the re-install it won't.
So, after the re-install I copied my Mac app to Applications and ran it. It died almost instantly. Running it from a terminal produces this error in all the output:
In the past I have also installed XQuartx as a pre-requisite for Wine, which worked previously using WineHQ's Mac builds, but this time it didn't work. After installing XQuartz the same error is shown in the terminal. From looking at the XQuartz website it appears it should contain the FreeType font library but there is no sign of it after installation. I have searched the entire hard drive for "freetype" and there are zero results.Wine cannot find the FreeType font library. To enable Wine to
use TrueType fonts please install a version of FreeType greater than
or equal to 2.0.5.
I tried building Wine using "--without-freetype", which built fine but then Wine failed to load my Windows app during initialisation (of Wine). It errored on something else to do with fonts, and saying there was a division by zero.
Do you have any advice on how to overcome this latest issue? Then I can get back to trying your other advice.
Re: How to build the portable version?
I’m assuming you were using brew for dependencies that’s a good idea as brew placing symlinks into /usr/local will make it seems like everything is packaged nicely when that’s not the case.adamAC wrote: ↑Tue Jul 07, 2020 6:06 am Thanks again for all your help and guidance.
I decided to re-install Catalina as I had numerous version of Wine installed and it got quite messy. Also, this will be a good test for end-user testing as this Mac had all the dev tools installed whereas after the re-install it won't.
Seems you didn’t provide an rpath configuration at build time so I knows you check /opt/X11/lib for libraries.adamAC wrote: ↑Tue Jul 07, 2020 6:06 am So, after the re-install I copied my Mac app to Applications and ran it. It died almost instantly. Running it from a terminal produces this error in all the output:
Wine cannot find the FreeType font library. To enable Wine to
use TrueType fonts please install a version of FreeType greater than
or equal to 2.0.5.
Winehq compiles have rpath set for /opt/X11/lib so wine will check the standard locations like /usr/lib and /usr/local/lib etc but will also check /opt/X11/lib.adamAC wrote: ↑Tue Jul 07, 2020 6:06 am In the past I have also installed XQuartx as a pre-requisite for Wine, which worked previously using WineHQ's Mac builds, but this time it didn't work. After installing XQuartz the same error is shown in the terminal. From looking at the XQuartz website it appears it should contain the FreeType font library but there is no sign of it after installation. I have searched the entire hard drive for "freetype" and there are zero results.
I tried building Wine using "--without-freetype", which built fine but then Wine failed to load my Windows app during initialisation (of Wine). It errored on something else to do with fonts, and saying there was a division by zero.
Do you have any advice on how to overcome this latest issue? Then I can get back to trying your other advice.
You need to search for libfreetype to find it.
Yeah don’t built wine without freetype it’s not a good idea.
Use the following exports;
Code: Select all
export C_INCLUDE_PATH="/opt/X11/include"
export LIBRARY_PATH="/opt/X11/lib”
export LFFLAGS=" -Wl,-rpath,/opt/X11/lib”
This isn’t perfect but will get you building wine using XQuartz provided files, plus being rpath set so wine64 will know where to find the needed dylibs at run time.
Re: How to build the portable version?
Many thanks again for your help.
I have added the following, as you suggested...
The file it is moaning about is located in "Resources/wine-home/usr/bin/lib64" in the Mac app. Somehow in making those new exports changes it has lost where these libraries are located.
Any ideas?
I have added the following, as you suggested...
...which runs fine on my dev Mac but now when I run Wine on Catalina it fails with the following, almost instantly:Gcenx wrote: ↑Tue Jul 07, 2020 12:52 pm Use the following exports;Code: Select all
export C_INCLUDE_PATH="/opt/X11/include" export LIBRARY_PATH="/opt/X11/lib” export LFFLAGS=" -Wl,-rpath,/opt/X11/lib”
So, I think this is failing earlier than before.dyld: Library not loaded: @rpath/libwine.1.dylib
Referenced from: /Applications/xxxxxxxx.app/Contents/MacOS/../Resources/wine-home/usr/bin/wine64
Reason: image not found
The file it is moaning about is located in "Resources/wine-home/usr/bin/lib64" in the Mac app. Somehow in making those new exports changes it has lost where these libraries are located.
Any ideas?
Re: How to build the portable version?
The exports were to be used at configure/make time only, did you also include those within the bash wrapper?adamAC wrote: ↑Wed Jul 08, 2020 7:19 am Many thanks again for your help.
I have added the following, as you suggested...
...which runs fine on my dev Mac but now when I run Wine on Catalina it fails with the following, almost instantly:Gcenx wrote: ↑Tue Jul 07, 2020 12:52 pm Use the following exports;Code: Select all
export C_INCLUDE_PATH="/opt/X11/include" export LIBRARY_PATH="/opt/X11/lib” export LFFLAGS=" -Wl,-rpath,/opt/X11/lib”
So, I think this is failing earlier than before.dyld: Library not loaded: @rpath/libwine.1.dylib
Referenced from: /Applications/xxxxxxxx.app/Contents/MacOS/../Resources/wine-home/usr/bin/wine64
Reason: image not found
The file it is moaning about is located in "Resources/wine-home/usr/bin/lib64" in the Mac app. Somehow in making those new exports changes it has lost where these libraries are located.
Any ideas?
As a workaround you could add the following to your apps bash wrapper;
Code: Select all
export dir=$(dirname "$0")
export DYLD_FALLBACK_LIBRARY_PATH=“/usr/lib:/usr/local/lib:/opt/X11/lib:${dir}/../Resources/wine-home/usr/bin/lib64”
dir gets the current path of where it’s launched from, meaning the wrapper can be moved to another location/renames and still function that or you hardcoded it but I wouldn’t do that for an app wrapper.
Re: How to build the portable version?
I only added them to the Mac I was building Wine on. I made no changes to the Mac running Catalina, except for dropping on the updated Mac app.
I have done this but I get exactly the same error. I did slightly modify what you suggested as the lib64 path at the end should be "Resources/wine-home/usr/Lib64", i.e. no "bin".Gcenx wrote: ↑Wed Jul 08, 2020 9:26 am As a workaround you could add the following to your apps bash wrapper;This might be slightly off but you should get the idea, this shouldn’t be required. (SIP will wipe the contents of DYLD_FALLBACK_LIBRARY_PATH and some other exports after spawning a single process)Code: Select all
export dir=$(dirname "$0") export DYLD_FALLBACK_LIBRARY_PATH=“/usr/lib:/usr/local/lib:/opt/X11/lib:${dir}/../Resources/wine-home/usr/bin/lib64”
dir gets the current path of where it’s launched from, meaning the wrapper can be moved to another location/renames and still function that or you hardcoded it but I wouldn’t do that for an app wrapper.
Would you possibly be able to create me a build of v4.0.4 with XML support for me to test? That may give us some indication as to whether some of my problems are in the build or on Catalina. Thanks.
Re: How to build the portable version?
Quick update....
After some messing about I have finally managed to solve this latest issue with libwine. Firstly, I was compressing the Mac app on my dev Mac and transferring it over to Catalina, to save time. Well, I was using ZIP which was not storing the symbolic links. So that bit is now sorted.
After that, I still had the FreeType library issue. I then re-instated your 2 proposed new exports and that has solved that. So, the app is now successfully launching on Catalina.
So, thank you for all your help on that bit.
Now....back to the problem of files and folders not appearing on Catalina. There is a little update on this. If I launch the Mac app script in my Mac app from a terminal then all files and folders are shown. If I launch the Mac app directly from Finder then they are missing, as before. So, as you quite rightly pointed out, launching from a terminal will inherit the permissions from the terminal process.
I have added my Mac app to allow Full Disk Access in System Preferences -> Security & Privacy but those files and folders are still not visible.
I will now take a look at this "quarantine/translocation flag(s)" that you mentioned before.
After some messing about I have finally managed to solve this latest issue with libwine. Firstly, I was compressing the Mac app on my dev Mac and transferring it over to Catalina, to save time. Well, I was using ZIP which was not storing the symbolic links. So that bit is now sorted.
After that, I still had the FreeType library issue. I then re-instated your 2 proposed new exports and that has solved that. So, the app is now successfully launching on Catalina.
So, thank you for all your help on that bit.
Now....back to the problem of files and folders not appearing on Catalina. There is a little update on this. If I launch the Mac app script in my Mac app from a terminal then all files and folders are shown. If I launch the Mac app directly from Finder then they are missing, as before. So, as you quite rightly pointed out, launching from a terminal will inherit the permissions from the terminal process.
I have added my Mac app to allow Full Disk Access in System Preferences -> Security & Privacy but those files and folders are still not visible.
I will now take a look at this "quarantine/translocation flag(s)" that you mentioned before.
Re: How to build the portable version?
Yeah zip archives are not a good way to distribute software, the correct way is ether a pkg installer or a dmg both are officially supported mediums.
Does your app have a valid BundleID? Not providing one will also cause issues and block it from being able to request permissions and stop it from being saved as allowed/disallowed
Does your app have a valid BundleID? Not providing one will also cause issues and block it from being able to request permissions and stop it from being saved as allowed/disallowed
Re: How to build the portable version?
For some reason, I thought that the Mac zip files DID support symbolic links
![Confused :?](./images/smilies/icon_confused.gif)
It DIDN'T have a BundleID at all. The Info.plist file was auto-generated by WineBundler. I have edited that file before to change the app name and such like but never added anything to it. So, I have now added "CFBundleIdentifier" to be "com.<company>.<app>" but launching the app still does not show "My Documents" or some folders and files, and there are no requests to access these locations. Even having my app manually added to "Security and Privacy" for "Full Disk Access" still doesn't show these locations and files.
Re: How to build the portable version?
Yeah I fell into the same trap as you did at first, it’s possible to use other archive formats but most won’t work natively on macOS that it will only supports the most recent releases
This could be a few things,adamAC wrote: ↑Mon Jul 13, 2020 3:39 am It DIDN'T have a BundleID at all. The Info.plist file was auto-generated by WineBundler. I have edited that file before to change the app name and such like but never added anything to it. So, I have now added "CFBundleIdentifier" to be "com.<company>.<app>" but launching the app still does not show "My Documents" or some folders and files, and there are no requests to access these locations. Even having my app manually added to "Security and Privacy" for "Full Disk Access" still doesn't show these locations and files.
Your system tccd database could need to be wiped (maybe?, can’t be sure)
Or it’s due to you using a bash script over an actual binary
Or lastly the app bundle could be missing something else not just the BundleID
Re: How to build the portable version?
I doubt it is this as this is happening on 3 different Macs, and I have wiped and re-installed macOS on 2 and the problem still remains.
That is possible. As I am no expert with Macs or Mac apps I have no idea.
Possibly. The one I was using was generated by WineBundler. I have since edited it to drop in the BundleID. Here is what I currently have:
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleExecutable</key>
<string>appname</string>
<key>CFBundleGetInfoString</key>
<string>appname</string>
<key>CFBundleIconFile</key>
<string>appname</string>
<key>CFBundleName</key>
<string>appname</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleSignature</key>
<string>4242</string>
<key>NSHighResolutionCapable</key>
<true/>
<key>CFBundleIdentifier</key>
<string>com.companyname.appname</string>
</dict>
</plist>
As I said previously, this would work if I launched this app from a Terminal. However, I have since "cleaned up" my Mac app and this has stopped working. I didn't really do much. However, I did remove all the user folders inside the Mac app in Wine (i.e. C:\Users). I assume that on launching Wine a new folder is created in here for the current Mac user. However, there is no "Documents" folder created. Could this be the problem?
Ideally, I need the "My Documents" in Wine to point to the Documents of the real current Mac user, as well as the "Desktop".
Re: How to build the portable version?
If the system was clean then yeah it’s not lightly.
A lot of things change between Mojave and Catalina and above, it’s not like Apple always explains all of these changes in an easy to understand manner (or at all)
I’d removeadamAC wrote: ↑Tue Jul 14, 2020 7:35 am Possibly. The one I was using was generated by WineBundler. I have since edited it to drop in the BundleID. Here is what I currently have:
*appname is the name of the app, and companyname is our company. These have been replaced in this snippet.Code: Select all
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleExecutable</key> <string>appname</string> <key>CFBundleGetInfoString</key> <string>appname</string> <key>CFBundleIconFile</key> <string>appname</string> <key>CFBundleName</key> <string>appname</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleSignature</key> <string>4242</string> <key>NSHighResolutionCapable</key> <true/> <key>CFBundleIdentifier</key> <string>com.companyname.appname</string> </dict> </plist>
Code: Select all
<key>CFBundleSignature</key>
<string>4242</string>
I think the issue is caused by the key you added (see the above comment) causing an invalid signature meaning macOS will just refuse it access to the protected locations.adamAC wrote: ↑Tue Jul 14, 2020 7:35 am As I said previously, this would work if I launched this app from a Terminal. However, I have since "cleaned up" my Mac app and this has stopped working. I didn't really do much. However, I did remove all the user folders inside the Mac app in Wine (i.e. C:\Users). I assume that on launching Wine a new folder is created in here for the current Mac user. However, there is no "Documents" folder created. Could this be the problem?
Ideally, I need the "My Documents" in Wine to point to the Documents of the real current Mac user, as well as the "Desktop".
On launch wine(32on64/64) generates symlinks for directories it knows to map like Documents etc, upon exit the symlinks are removed.
Re: How to build the portable version?
The app is NOT code-signed and NOT notarized.Gcenx wrote: ↑Tue Jul 14, 2020 11:05 am I’d removeThis could cause an issue unless your really did code-sign and notarize your app bundle, but any change made after this will cause the signature to become invalid.Code: Select all
<key>CFBundleSignature</key> <string>4242</string>
I will remove this part tomorrow and give it a try. Hopefully this will solve this little riddle. Fingers crossed.
Will try this tomorrow. Hopefully it will be.
This does not seem to be happening. If I view the contents of the Mac app whilst the app is running then there are no symlinks created in the user folder in the Wine file structure (e.g. C:\Users\<user>\)
Re: How to build the portable version?
So, I have removed this and tried it again but the app still does not show files and some folders if I launch the app directly. I am never prompted to allow access either. If I launch it from the Terminal then I can see them, except for My Documents, just as before.Gcenx wrote: ↑Tue Jul 14, 2020 11:05 am I’d removeThis could cause an issue unless your really did code-sign and notarize your app bundle, but any change made after this will cause the signature to become invalid.Code: Select all
<key>CFBundleSignature</key> <string>4242</string>
I think the issue is caused by the key you added (see the above comment) causing an invalid signature meaning macOS will just refuse it access to the protected locations.
I have checked this again, and there are no links created for My Documents in the Wine file structure when the app is running. Clicking on "My Documents" in a file dialog shows nothing, and it thinks that you are not in a valid location, i.e. you aren't in "My Documents". I have manually created a "My Documents" folder in C:\users\<user>\ and I can now save, open, and view any file saved in that location, but this is NOT my "Documents" from the Mac user, which I cannot see anything in. So I think you are right that this is a permissions issue. It seems that it is failing to create the symlink to the Mac user's Documents folders, as well as not having access to other areas too.
I have then tried manually creating a symlink for "My Documents", and that now allows "My Documents" to appear in my app. However, the folder is still empty.
I have just tested the Mac app on Mojave and High Sierra and the symlinks are NOT created on there either. If I use a version of Wine downloaded from WineHQ then it creates those links on Mojave and High Sierra. It also creates those links on Catalina too but only when launched from a Terminal. So I guess there is a problem with this build I created.
Also, on all macOSs where the symlinks are successfully created they remain AFTER the Mac app has closed.
Re: How to build the portable version?
Scratch the wine removing symlinks on exit, that’s something I handle along with a whole host of other things.
The not making symlinks is strange as it should at least function on the system it was built on, unless you’re making a recent version of wine as the more recent releases no longer create some symlinks by default instead opting for making directories within the wineprefix.
You “could” manually create the symlinks to the users directories ahead of time make the symlink to “~/Documents” for example so it will function on any user.
You will still need to handle fixing the wineprefix permissions for each user as wine doesn’t handle these things on its own
The not making symlinks is strange as it should at least function on the system it was built on, unless you’re making a recent version of wine as the more recent releases no longer create some symlinks by default instead opting for making directories within the wineprefix.
You “could” manually create the symlinks to the users directories ahead of time make the symlink to “~/Documents” for example so it will function on any user.
You will still need to handle fixing the wineprefix permissions for each user as wine doesn’t handle these things on its own