Run on macOS

[arkypita]

I have opened this thread for ones who like to collaborate in running LaserGRBL under macOS using PlayOnMac as it was done in Linux.
This thread could be a good starting point: #1764 but please write here about macOS howto.

[cbagwell]

I would like to give LaserGRBL a try but do not have Windows OS handy. My laptop is a MacBook Air so PlayOnMac is ideal for me but I might resort to PlayOnLinux under Docker as a backup. Here is what I have done so far.

I started with PlayOnMac 4.4.3 and downloaded install.exe for LaserGRBL v4.8.0. I read over POL_LaserGRBL_setup.sh in GitHub and performed its steps manually using PlayOnMac GUI; mostly requesting to install gdiplus and msxml3 and using a win32 prefix. I ran into this issue downloading gdiplus and used its work around to continue:

https://www.playonmac.com/en/app-518-POL_Install_gdiplus.html

After installing and running, I got an error message that wine-mono was not installed. I'm not sure why but a common search result recommends installing manually as a work around. I downloaded wine-mono-7.1.1-x86.msi and installed it into same wineprefix from here:

https://dl.winehq.org/wine/wine-mono/7.1.1/

Now I am able to get further into running but it crashes. The crash looks related to gdiplus and msxml3 dependencies. I'm not familiar with syswow64 but perhaps its mixing 32-bit and 64-bit libraries? That is the hardest part with using Wine on current Mac's since ability to launch 32-bit executables was removed in Mac Catalina and Wine developers is having to do some kind of work arounds to recover from that.

Running wine- LaserGRBL.exe (Working directory : ..../Library/PlayOnMac/wineprefix/LaserGRBL/drive_c/Program Files (x86)/LaserGRBL)
0094:err:plugplay:process_IOService_Device object 0xa203
0094:err:plugplay:process_IOService_Device Unable to create plug in interface for USB deviceobject 0xa207
0094:err:plugplay:process_IOService_Device Unable to create plug in interface for USB deviceobject 0xa20b
0094:err:plugplay:process_IOService_Device Unable to create plug in interface for USB deviceobject 0xa20f
0094:err:plugplay:process_IOService_Device Unable to create plug in interface for USB deviceobject 0xa213
0094:err:plugplay:process_IOService_Device Unable to create plug in interface for USB deviceobject 0xa217
0024:err:ole:apartment_add_dll couldn't load in-process dll L"C:\\windows\\syswow64\\msxml3.dll"
0024:err:ole:com_get_class_object no class object {079aa557-4a18-424a-8eee-e39f0a8d41b9} could be created for context 0x1
0024:err:ole:apartment_add_dll couldn't load in-process dll L"C:\\windows\\syswow64\\msxml3.dll"
0024:err:ole:com_get_class_object no class object {079aa557-4a18-424a-8eee-e39f0a8d41b9} could be created for context 0x1
0024:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
0024:fixme:nls:GetFileMUIPath stub: 0x10, L"C:\\windows\\system32\\tzres.dll", (null), 0032EF78, 0016A780, 0032EF7C, 0032EF70
0024:fixme:nls:GetFileMUIPath stub: 0x10, L"C:\\windows\\system32\\tzres.dll", (null), 0032EF78, 0016A780, 0032EF7C, 0032EF70
0024:fixme:file:ReplaceFileW Ignoring flags 2
0024:fixme:sync:NtSetTimerResolution (10000,1,0x32f8d4), stub!
exception inside UnhandledException handler: (null) assembly:C:\windows\mono\mono-2.0\lib\mono\4.5\mscorlib.dll type:TypeInitializationException member:(null)

[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'System.Drawing.GDIPlus' threw an exception. ---> System.DllNotFoundException: gdiplus assembly:<unknown  at (wrapper managed-to-native) System.Drawing.GDIPlus.GdiplusStartup(ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
  at System.Drawing.GDIPlus..cctor () [0x000b0] in <fd3713c437bd42ab8b3c0c3cae9b0f2f>:0 
   --- End of inner exception stack trace ---
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_generic_class_init(intptr)
  at System.Drawing.FontFamily..ctor (System.Drawing.Text.GenericFontFamilies genericFamily) [0x00053] in <fd3713c437bd42ab8b3c0c3cae9b0f2f>:0 
  at (wrapper remoting-invoke-with-check) System.Drawing.FontFamily..ctor(System.Drawing.Text.GenericFontFamilies)
  at System.Drawing.FontFamily.get_GenericSansSerif () [0x00000] in <fd3713c437bd42ab8b3c0c3cae9b0f2f>:0 
  at System.Drawing.Font.CreateFont (System.String familyName, System.Single emSize, System.Drawing.FontStyle style, System.Drawing.GraphicsUnit unit, System.Byte charSet, System.Boolean isVertical) [  at System.Drawing.Font..ctor (System.String familyName, System.Single emSize, System.Drawing.FontStyle style, System.Drawing.GraphicsUnit unit, System.Byte gdiCharSet, System.Boolean gdiVerticalFont  at System.Drawing.Font..ctor (System.String familyName, System.Single emSize, System.String systemName) [0x00000] in <fd3713c437bd42ab8b3c0c3cae9b0f2f>:0 
  at (wrapper remoting-invoke-with-check) System.Drawing.Font..ctor(string,single,string)
  at System.Drawing.SystemFonts.get_DefaultFont () [0x00000] in <fd3713c437bd42ab8b3c0c3cae9b0f2f>:0 
  at System.Windows.Forms.Control.get_DefaultFont () [0x0000e] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at System.Windows.Forms.Control.get_Font () [0x00088] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at System.Windows.Forms.RichTextBox.get_Font () [0x00001] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at System.Windows.Forms.Control.get_FontHeight () [0x000a9] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at System.Windows.Forms.TextBoxBase.get_PreferredHeight () [0x00001] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at System.Windows.Forms.TextBoxBase.AdjustHeight (System.Boolean returnIfAnchored) [0x00080] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at System.Windows.Forms.TextBoxBase.set_Multiline (System.Boolean value) [0x00072] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at System.Windows.Forms.RichTextBox.set_Multiline (System.Boolean value) [0x00001] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at System.Windows.Forms.RichTextBox..ctor () [0x0006f] in <24e72a8b81ea40a082ff6bce056ee22e>:0 
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.RichTextBox..ctor()
  at LaserGRBL.ExceptionManager.InitializeComponent () [0x0001b] in <ed27c3e0a09c43beac0131b826af8641>:0 
  at LaserGRBL.ExceptionManager..ctor () [0x00006] in <ed27c3e0a09c43beac0131b826af8641>:0 
  at (wrapper remoting-invoke-with-check) LaserGRBL.ExceptionManager..ctor()
  at LaserGRBL.ExceptionManager.CreateAndShow (System.Exception ex, System.Boolean cancontinue, System.Boolean manual) [0x00000] in <ed27c3e0a09c43beac0131b826af8641>:0 

[cbagwell]

I reinstalled LaserGRBL using same instructions except this time I skipped installing gdiplus and msxml3. This time the GUI comes all the way up. The COM port drop down is empty but I'm guessing I can follow PlayOnLinux instructions to fix that part.

I browsed around and most menus seemed to work.

It wasn't until I attempted to load a small jpeg that I had an issue. An Import Raster Image window pops up and in lower right hand corner I see a bouncing status bar but the image never finishes loading. At same instance, I get this printed to wine debug log which I assume means that image imports is likely the reason for switching to external gidplus in the first place.

0134:fixme:gdiplus:GdipSetImageAttributesThreshold not implemented

So now I'm back to trying to use external gdiplus. Some initial internet searches make me think that I need to "brew install mono-libgdiplus" to resolve the "System.DllNotFoundException: gdiplus assembly:<unknown " issue when using external gdiplus but it didn't seem to help. I need to figure out how to enable more mono debug prints to confirm if its attempting to use or doesn't find /usr/local/lib/libgdiplus.dylib.

[cbagwell]

By using export MONO_LOG_LEVEL=debug, it looks like it couldn't find the installed gdiplus.dll even though I see it was installed into drive_c/windows/syswow64. If I copied from that directory and renamed to libgdiplus.dll over to LaserGRBL directory then its found and app loads. Behavior wise, it seems to work same as when I just don't install gdiplus and rely on default behavior... that is when I load a jpeg image, the app GUI spins for ever waiting for the load to finish.

[arkypita]

Hi @cbagwell, thanks for your effort and your contribution!
You are already a couple of steps ahead of me, I also found myself stuck on crash and abandoned my searches. I'm testing in a virtual machine with BigSur.

[arkypita]

If I run with debug option, here is the log file: playonlinux.log

[arkypita]

My main error seem to be module:fixup_imports_ilonly mscoree.dll not found

0024:err:module:fixup_imports_ilonly mscoree.dll not found, IL-only binary L"LaserGRBL.exe" cannot be loaded
0024:err:module:LdrInitializeThunk Importing dlls for L"C:\\Program Files (x86)\\LaserGRBL\\LaserGRBL.exe" failed, status c0000135

[cbagwell]

In case it helps, I ran export MONO_LOG_LEVEL=debug from a terminal and then launched the PlayOnMac from terminal using /Applications/PlayOnMac.app/Contents/MacOS/playonmac so it would be visible to LaserGRBL. That added extra debug prints to log and help me confirm it wasn't looking in many subdirectories for gdiplus.dll nor looking for libgdiplus.dylib.

I see from the log file the main differences between our runs is that you installed botnet instead of mono. I'll give that a try as well.

One update is that I saw the internal version of wine in PlayOnMac is currently wine-6.0 and I saw a table on WineHQ that said wine-mono-6.0.0 matches wine-6.0 so I tried that older version of wine-mono. The app failed to run with wine-mono-6.0.0 at all. I'll have to reproduce that run because if I remember right it failed to find mscoree.dll as well; which would be an interesting match with dotnet.

[cbagwell]

I hit lots of dead ends so I decided to download and try the 14 day trail of crossover to see if it worked any better. I installed the app under crossover and it launched without me needing to manually install wine-mono or any other override software. When I loaded a jpeg, it still had the problem where it didn't display the image and a infinite status bouncer in lower right corner.

I decided to go into all menus and toggle most options just to get a feel for what all didn't work. Serial port list being empty had some side effects related to not connected to machine but otherwise everything seemed fine.

In the Import Raster Image screen that appeared to not be working, I started toggling things. Then I realized it is working for most part. If I select 1bt BW Dither or Passthrough then the image displays and status bar goes away. The issue is limited to Line to Line Tracing and Vectorizel conversions tools and since the default option doesn't work the screen appeared broke to me. Centerline also complains about only working on 32-bit windows and so make sense since I create a 32bit wineprefix.

All the image processing options then appeared to work and I was able to create a burnable image using 1bt BW Dither.

After this, I went back to my PlayOnMac install where I used LaserGRL+wine-mono-7.1.1 and no overrides and it works exactly the same as crossover.

So I hope that means we are close to working with PlayOnMac. BTW, Nice app now that I get to test drive. I'm motivated to continue for a while longer to get this app in my toolbox.

[cbagwell]

I've not previous messed with C# but I'm happy to report I successfully recompiled LaserGRBL using Mono on Mac using "xbuild LaserGRBL.lsn". I can not run the result on Mac directly because WinForms is only supported with mono32 and Mac's removal of 32-bit support broke that support.

I can copy the result to my PlayOnMac install though and do some good old fashion WriteLine debugging within Wine quickly.

I can confirm my Import Image lockup is its never returning from Threshold() function in ImageTransform.cs:

LaserGRBL/LaserGRBL/RasterConverter/ImageTransform.cs

Line 72 in 9d5af15

imageAttr.SetThreshold(threshold);

And also makes sense from debug print from wine itself:

0118:fixme:gdiplus:GdipSetImageAttributesThreshold not implemented

So for sure there is an issue with internal version of gdiplus in at least wine-6.0 that PlayOnMac is using.

[cbagwell]

Some good news. Now that I know for sure my main issue is with wine's internal gdiplus, I installed the external gdiplus and it failed working with it but I figured out what's wrong. I don't exactly know why the install is going wrong but I figured out a way to get it working.

I created a new win64 winprefix (you'll see LaserGRBL64 to reflect this since previously I tried win32... I don't know if it matters yet) and installed LaserGRBL+wine-mono+gdiplus. For what ever reason, the gdiplus installed a 32-bit DLL in the 64-bit directory (yeah, windows is weird with system32 meaning 64-bit and syswow64 meaning 32-bit) and it leaves what I think is original wine version under the 32-bit directory. If I copy Window's real gdiplus over to the correct location then when I run LaserGRBL, I have no issues with importing jpegs.

cp ~/Library/PlayOnMac/wineprefix/LaserGRBL64/drive_/windows/system32/gdiplus.dll ~/Library/PlayOnMac/wineprefix/LaserGRBL64/drive_c/windows/syswow64/gdiplus.dll

Now I get to move on to talking over the serial port and actually burning images.

[arkypita]

That's a great news!

About COM port i think you should be able to see it in your macos system first, than map the port in wine.

Most usb-serial chipset need driver installed in windows to make the OS able to see them as a COM, don't know if it's the same in macos.

[cbagwell]

I decided to do a bit more investigating on why gdiplus install is any issue. It looks like an issue unique to PlayOnMac and/or the wine32on64version of wine its using. When you request a win32 wineprefix to be created, its still creates a win64. Easy way to confirm is you'll see "Program Files (x86)" directory created.

I compared with crossover-21 and it does correctly create a win32 wineprefix. If you use its GUI to install "GDI+" (as opposed to gdiplus") into the LaserGRBL Bottle then its installed in correct location and jpegs can be loaded.

I looked around at other free options and looks like using homebrew and working from CLI using Linux instructions is pretty good option (it can create win32 wineprefix). Install 2 main wine items. It has to be this special cask version to get win32 support on recent Mac's.

brew install --cask --no-quarantine gcenx/wine/wine-crossover
brew install winetrick

Now to create a win32 wineprefix at ~/.wine32 as part of installing LaserGRBL, install gdiplus as well as wine-mono, and then run it:

WINEARCH=win32 WINEPREFIX=~/.wine32 wine ~/Downloads/install.exe
WINEARCH=win32 WINEPREFIX=~/.wine32 winetricks gdiplus
WINEARCH=win32 WINEPREFIX=~/.wine32 msiexec /i ~/Downloads/wine-mono-7.1.1-x86.msi
WINEARCH=win32 WINEPREFIX=~/.wine32 wine "/Users/"`whoami`"/.wine32/drive_c/Program Files/LaserGRBL/LaserGRBL.exe"

Testing wise, both the PlayOnMac and wine-crossover from homebrew work about the same. I loaded a wider range of jpeg and found several that crash LaserGRBL though. Something about commercial Crossover-21 is able to handle more images without crashing.