ElementalWarrior

Alright, lets see if I can make this a bit simpler.
I think in you should just be able to clone the dll from here:
https://github.com/ElementalWarrior/wine-wintypes.dll-for-affinity
and copy it to the application directory.
To make that even simpler, I'm trying to upstream a winetricks verb that both downloads Windows.winmd and wintypes.dll. 
https://github.com/ElementalWarrior/winetricks/tree/add-affinity
Install the application, clone this repo, and run `./src/winetricks affinity` from a fresh prefix, and see if it works.
After running this, you should be able to use bone stock wine (because apparently I was incorrect that you could do that before)
Note
My wintypes.dll does not include all the functionality the wine one does. But it doesn't appear to cause issue.
Note 2
This does not resolve the installer issues, but this change might, if they approve it.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8367
Note 3
Trying to make progress with open source contributions is kinda like herding cats. Angry angry cats.

STFU; complain somewhere else.
 

STFU; complain somewhere else.
 

STFU; complain somewhere else.
 

STFU; complain somewhere else.
 

On modern wine-10.3, you can start  affinity photo without any of my changes. To install it, this commit is still needed
commit e27add553a490b3fdf91051251f85a83a93f51c7 (ElementalWarrior/affinity-photo2-wine10.3, affinity-photo2-wine10.3) Author: James McDonnell <topgamer7@gmail.com> Date: Sun Feb 26 12:56:24 2023 -0800 shell32/iconcache: Call LoadIconW diff --git a/dlls/shell32/iconcache.c b/dlls/shell32/iconcache.c index 8f9519d2ca8..7e9a37db44d 100644 --- a/dlls/shell32/iconcache.c +++ b/dlls/shell32/iconcache.c @@ -1007,9 +1007,7 @@ HRESULT WINAPI SHGetStockIconInfo(SHSTOCKICONID id, UINT flags, SHSTOCKICONINFO if (flags) FIXME("flags 0x%x not implemented\n", flags); - sii->hIcon = NULL; - if (flags & SHGSI_ICON) - sii->hIcon = LoadIconW(GetModuleHandleW(sii->szPath), MAKEINTRESOURCEW(sii->iIcon)); + sii->hIcon = LoadIconW(GetModuleHandleW(L"shell32.dll"), MAKEINTRESOURCEW(IDI_SHELL_FILE)); sii->iSysImageIndex = -1; TRACE("%3d: returning %s (%d)\n", id, debugstr_w(sii->szPath), sii->iIcon);  

I found the best performance was by using wayland and vulkan. Which you can do by running
winetricks renderer=vulkan and then set the DISPLAY env var to nothing:
export DISPLAY= NOTE if you set the env var like this, anything you run from the terminal you applied this to may be affected.
Or just run wine + photo.exe like so:
DISPLAY= wine ~/.wine/drive_c/Program\ Files/Affinity/Photo\ 2/Photo.exe Note that you may need to change where Photo.exe is installed if you use a different wine prefix.

On modern wine-10.3, you can start  affinity photo without any of my changes. To install it, this commit is still needed
commit e27add553a490b3fdf91051251f85a83a93f51c7 (ElementalWarrior/affinity-photo2-wine10.3, affinity-photo2-wine10.3) Author: James McDonnell <topgamer7@gmail.com> Date: Sun Feb 26 12:56:24 2023 -0800 shell32/iconcache: Call LoadIconW diff --git a/dlls/shell32/iconcache.c b/dlls/shell32/iconcache.c index 8f9519d2ca8..7e9a37db44d 100644 --- a/dlls/shell32/iconcache.c +++ b/dlls/shell32/iconcache.c @@ -1007,9 +1007,7 @@ HRESULT WINAPI SHGetStockIconInfo(SHSTOCKICONID id, UINT flags, SHSTOCKICONINFO if (flags) FIXME("flags 0x%x not implemented\n", flags); - sii->hIcon = NULL; - if (flags & SHGSI_ICON) - sii->hIcon = LoadIconW(GetModuleHandleW(sii->szPath), MAKEINTRESOURCEW(sii->iIcon)); + sii->hIcon = LoadIconW(GetModuleHandleW(L"shell32.dll"), MAKEINTRESOURCEW(IDI_SHELL_FILE)); sii->iSysImageIndex = -1; TRACE("%3d: returning %s (%d)\n", id, debugstr_w(sii->szPath), sii->iIcon);  

I found the best performance was by using wayland and vulkan. Which you can do by running
winetricks renderer=vulkan and then set the DISPLAY env var to nothing:
export DISPLAY= NOTE if you set the env var like this, anything you run from the terminal you applied this to may be affected.
Or just run wine + photo.exe like so:
DISPLAY= wine ~/.wine/drive_c/Program\ Files/Affinity/Photo\ 2/Photo.exe Note that you may need to change where Photo.exe is installed if you use a different wine prefix.

On modern wine-10.3, you can start  affinity photo without any of my changes. To install it, this commit is still needed
commit e27add553a490b3fdf91051251f85a83a93f51c7 (ElementalWarrior/affinity-photo2-wine10.3, affinity-photo2-wine10.3) Author: James McDonnell <topgamer7@gmail.com> Date: Sun Feb 26 12:56:24 2023 -0800 shell32/iconcache: Call LoadIconW diff --git a/dlls/shell32/iconcache.c b/dlls/shell32/iconcache.c index 8f9519d2ca8..7e9a37db44d 100644 --- a/dlls/shell32/iconcache.c +++ b/dlls/shell32/iconcache.c @@ -1007,9 +1007,7 @@ HRESULT WINAPI SHGetStockIconInfo(SHSTOCKICONID id, UINT flags, SHSTOCKICONINFO if (flags) FIXME("flags 0x%x not implemented\n", flags); - sii->hIcon = NULL; - if (flags & SHGSI_ICON) - sii->hIcon = LoadIconW(GetModuleHandleW(sii->szPath), MAKEINTRESOURCEW(sii->iIcon)); + sii->hIcon = LoadIconW(GetModuleHandleW(L"shell32.dll"), MAKEINTRESOURCEW(IDI_SHELL_FILE)); sii->iSysImageIndex = -1; TRACE("%3d: returning %s (%d)\n", id, debugstr_w(sii->szPath), sii->iIcon);  

I found the best performance was by using wayland and vulkan. Which you can do by running
winetricks renderer=vulkan and then set the DISPLAY env var to nothing:
export DISPLAY= NOTE if you set the env var like this, anything you run from the terminal you applied this to may be affected.
Or just run wine + photo.exe like so:
DISPLAY= wine ~/.wine/drive_c/Program\ Files/Affinity/Photo\ 2/Photo.exe Note that you may need to change where Photo.exe is installed if you use a different wine prefix.

On modern wine-10.3, you can start  affinity photo without any of my changes. To install it, this commit is still needed
commit e27add553a490b3fdf91051251f85a83a93f51c7 (ElementalWarrior/affinity-photo2-wine10.3, affinity-photo2-wine10.3) Author: James McDonnell <topgamer7@gmail.com> Date: Sun Feb 26 12:56:24 2023 -0800 shell32/iconcache: Call LoadIconW diff --git a/dlls/shell32/iconcache.c b/dlls/shell32/iconcache.c index 8f9519d2ca8..7e9a37db44d 100644 --- a/dlls/shell32/iconcache.c +++ b/dlls/shell32/iconcache.c @@ -1007,9 +1007,7 @@ HRESULT WINAPI SHGetStockIconInfo(SHSTOCKICONID id, UINT flags, SHSTOCKICONINFO if (flags) FIXME("flags 0x%x not implemented\n", flags); - sii->hIcon = NULL; - if (flags & SHGSI_ICON) - sii->hIcon = LoadIconW(GetModuleHandleW(sii->szPath), MAKEINTRESOURCEW(sii->iIcon)); + sii->hIcon = LoadIconW(GetModuleHandleW(L"shell32.dll"), MAKEINTRESOURCEW(IDI_SHELL_FILE)); sii->iSysImageIndex = -1; TRACE("%3d: returning %s (%d)\n", id, debugstr_w(sii->szPath), sii->iIcon);  

Yeah, I was mostly referring to the bug in wine. Which happens regardless of building wine with whatever tooling they use.
Technically they can probably use whatever license for their packaging code they want, so long as they build wine in a separate process/repo. But I'm no lawyer, and I haven't looked into it.
Every once and a while i rebase my changes to latest wine to see if it is more stable and Vulkan/Wayland/etc works better. But not much has seemed to have improved.
It's a lot of work tracking down issues and trying to patch things. And I barely use graphics editing software.

Yeah, I was mostly referring to the bug in wine. Which happens regardless of building wine with whatever tooling they use.
Technically they can probably use whatever license for their packaging code they want, so long as they build wine in a separate process/repo. But I'm no lawyer, and I haven't looked into it.
Every once and a while i rebase my changes to latest wine to see if it is more stable and Vulkan/Wayland/etc works better. But not much has seemed to have improved.
It's a lot of work tracking down issues and trying to patch things. And I barely use graphics editing software.

While Apple mac's are very nice computers. I don't agree with their business practices. Primarily about how they treat their hardware. The fact that a device "owner" cannot simply replace a button, or a screen, without profit capture by Apple, and the replacement done by Apple. But also you cannot side load your own binaries onto their phones.
So I put my "vote" of my money, elsewhere.
 

I created another branch. Updated off the most recent wine changes. It's the bleeding edge, so you may see issues in other in it.
I also included recent WIP patches for vulkan child window handling. This **should** fix (**mostly**) using wayland and vulkan for affinity photo.
It did seem a bit buggy still. For example its a bit flickery at times, and it still didn't work on wine's d3d11 and below handling.
It still doesn't work when using pure wayland for me, only XWAYLAND works for me on sway.
But if you run Photo with the vulkan renderer, and dxvk installed. It should work somewhat normally.
If you don't want to muck with regedit to set the renderer, you can just send the environment variable: `WINE_D3D_CONFIG="renderer=vulkan"`.
So to be clear, this branch includes:
- Remi Bernon's child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
- Remi Bernon's transparent window changes: https://gitlab.winehq.org/wine/wine/-/merge_requests/6025#note_75558
- Alexandros Frantzis's work for vulkan + gl child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/6107
- __avg__'s patches for hardware acceleration: https://github.com/oh-ok/wine-affinity-patches/tree/main
- My changes, with some of them reverted in place of __avg__'s.
I could not get hardware acceleration working on AMD. Although AMD's OpenCL functionality is a bit a of a cluster f*** with regards to ROCM and HIP and all that crap going on. @__avg__ if you have thoughts on this, I'm happy to hear them
The branch is named affinity-photo2-wine9.13 -- You can find it here: https://gitlab.winehq.org/ElementalWarrior/wine/-/tree/affinity-photo2-wine9.13?ref_type=heads

Well I got opencl checked on amd. Although it doesn't work if dxvk is installed into the wineprefix.
New branch:
affinity-photo3-wine9.13-part3
I immediately call the clSetEventCallback. Which means it likely isn't working as expected. Because it should be asynchronous, after the job is done. But :shrug:.
I tried writing a wrapper function. But it just crashed. I'm not sure how easy it is to call PE functions from wine server process.

I found I was using a rocm driver from back in January. After installing opencl-amd from aur, the error from the driver went away.
Now I get a lot more opencl logs, but I'm guessing the opencl implementation in wine isn't good enough yet for amd here. I am seeing that clSetEventCallback issue as well.
0150:trace:opencl:clGetDeviceInfo (00005555777DDD80, 0x4039, 8, 00007FFFFE4F0F98, 0000000000000000) 0150:trace:opencl:clGetDeviceInfo (00005555777DDD80, 0x101f, 8, 00007FFFFE4F0F90, 0000000000000000) 0150:trace:opencl:clGetDeviceInfo (00005555777DDD80, 0x101f, 8, 00007FFFFE4F0F90, 0000000000000000) 0150:trace:opencl:clCreateBuffer (000055557D491230, 1, 4096, 0000000000000000, 00007FFFFE4F0EC0) :3:rocdevice.cpp :2418: 48075526256 us: [pid:718937 tid:0x79eeb281a740] Device=0x5555777ddd70, freeMem_ = 0x1feffeffc 0150:trace:opencl:clGetMemObjectInfo (000055557A39DC90, 4354, 8, 00007FFFFE4F0EC0, 0000000000000000) 0150:trace:opencl:clGetDeviceInfo (00005555777DDD80, 0x1035, 4, 00007FFFFE4F1000, 0000000000000000) 0150:trace:opencl:clEnqueueWriteBufferRect (000055557D6027F0, 0000555576884390, 0, 00007FFFFE4F0F80, 00007FFFFE4F0F80, 00007FFFFE4F0F98, 4, 0, 4, 0, 000079EE900D8000, 0, 0000000000000000, 0000000000000000) 0150:trace:opencl:clEnqueueFillBuffer (000055557D6027F0, 000055557A39DC90, 00007FFFFE4F0E70, 1, 0, 324, 0, 0000000000000000, 000079EB96992B90) 0150:trace:opencl:clSetEventCallback (0000555576A1D050, 0, 00006FFFE09FB207, 000079EB971D0C10) 0150:fixme:opencl:wrap_clSetEventCallback not yet implemented 0150:trace:opencl:clFlush (000055557D6027F0) :3:rocvirtual.cpp :724 : 48075526441 us: [pid:718937 tid:0x79ee8b1396c0] Arg0: void* buf = ptr:0x79edd2601000 obj:[0x79edd2601000-0x79edd2602000] :3:rocvirtual.cpp :799 : 48075526456 us: [pid:718937 tid:0x79ee8b1396c0] Arg2: uint pattern_size = val:1 :3:rocvirtual.cpp :799 : 48075526462 us: [pid:718937 tid:0x79ee8b1396c0] Arg3: uint alignment = val:16 :3:rocvirtual.cpp :799 : 48075526467 us: [pid:718937 tid:0x79ee8b1396c0] Arg4: ulong end_ptr = val:134062343721280 :3:rocvirtual.cpp :799 : 48075526471 us: [pid:718937 tid:0x79ee8b1396c0] Arg5: uint next_chunk = val:256 :3:rocvirtual.cpp :3028: 48075526476 us: [pid:718937 tid:0x79ee8b1396c0] ShaderName : __amd_rocclr_fillBufferAligned :3:rocvirtual.cpp :724 : 48075526487 us: [pid:718937 tid:0x79ee8b1396c0] Arg0: void* buf = ptr:0x79edd2601140 obj:[0x79edd2601000-0x79edd2602000] :3:rocvirtual.cpp :799 : 48075526494 us: [pid:718937 tid:0x79ee8b1396c0] Arg2: uint pattern_size = val:1 :3:rocvirtual.cpp :799 : 48075526499 us: [pid:718937 tid:0x79ee8b1396c0] Arg3: uint alignment = val:1 :3:rocvirtual.cpp :799 : 48075526504 us: [pid:718937 tid:0x79ee8b1396c0] Arg4: ulong end_ptr = val:134062343721284 :3:rocvirtual.cpp :799 : 48075526507 us: [pid:718937 tid:0x79ee8b1396c0] Arg5: uint next_chunk = val:256 :3:rocvirtual.cpp :3028: 48075526512 us: [pid:718937 tid:0x79ee8b1396c0] ShaderName : __amd_rocclr_fillBufferAligned :3:rocvirtual.hpp :66 : 48075526524 us: [pid:718937 tid:0x79ee8b1396c0] Host active wait for Signal = (0x79ee005fae00) for 100000 ns :3:rocvirtual.hpp :75 : 48075526632 us: [pid:718937 tid:0x79ee8b1396c0] Host blocked wait for Signal = (0x79ee005fae00)  

Alright, after reverting the commit causing the segfault, we have this:
affinity-photo2-wine9.13-part2
Nothing shows up when I include +opencl in WINEDEBUG
Which is kinda odd in itself I suppose

I created another branch. Updated off the most recent wine changes. It's the bleeding edge, so you may see issues in other in it.
I also included recent WIP patches for vulkan child window handling. This **should** fix (**mostly**) using wayland and vulkan for affinity photo.
It did seem a bit buggy still. For example its a bit flickery at times, and it still didn't work on wine's d3d11 and below handling.
It still doesn't work when using pure wayland for me, only XWAYLAND works for me on sway.
But if you run Photo with the vulkan renderer, and dxvk installed. It should work somewhat normally.
If you don't want to muck with regedit to set the renderer, you can just send the environment variable: `WINE_D3D_CONFIG="renderer=vulkan"`.
So to be clear, this branch includes:
- Remi Bernon's child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
- Remi Bernon's transparent window changes: https://gitlab.winehq.org/wine/wine/-/merge_requests/6025#note_75558
- Alexandros Frantzis's work for vulkan + gl child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/6107
- __avg__'s patches for hardware acceleration: https://github.com/oh-ok/wine-affinity-patches/tree/main
- My changes, with some of them reverted in place of __avg__'s.
I could not get hardware acceleration working on AMD. Although AMD's OpenCL functionality is a bit a of a cluster f*** with regards to ROCM and HIP and all that crap going on. @__avg__ if you have thoughts on this, I'm happy to hear them
The branch is named affinity-photo2-wine9.13 -- You can find it here: https://gitlab.winehq.org/ElementalWarrior/wine/-/tree/affinity-photo2-wine9.13?ref_type=heads

I created another branch. Updated off the most recent wine changes. It's the bleeding edge, so you may see issues in other in it.
I also included recent WIP patches for vulkan child window handling. This **should** fix (**mostly**) using wayland and vulkan for affinity photo.
It did seem a bit buggy still. For example its a bit flickery at times, and it still didn't work on wine's d3d11 and below handling.
It still doesn't work when using pure wayland for me, only XWAYLAND works for me on sway.
But if you run Photo with the vulkan renderer, and dxvk installed. It should work somewhat normally.
If you don't want to muck with regedit to set the renderer, you can just send the environment variable: `WINE_D3D_CONFIG="renderer=vulkan"`.
So to be clear, this branch includes:
- Remi Bernon's child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
- Remi Bernon's transparent window changes: https://gitlab.winehq.org/wine/wine/-/merge_requests/6025#note_75558
- Alexandros Frantzis's work for vulkan + gl child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/6107
- __avg__'s patches for hardware acceleration: https://github.com/oh-ok/wine-affinity-patches/tree/main
- My changes, with some of them reverted in place of __avg__'s.
I could not get hardware acceleration working on AMD. Although AMD's OpenCL functionality is a bit a of a cluster f*** with regards to ROCM and HIP and all that crap going on. @__avg__ if you have thoughts on this, I'm happy to hear them
The branch is named affinity-photo2-wine9.13 -- You can find it here: https://gitlab.winehq.org/ElementalWarrior/wine/-/tree/affinity-photo2-wine9.13?ref_type=heads

I created another branch. Updated off the most recent wine changes. It's the bleeding edge, so you may see issues in other in it.
I also included recent WIP patches for vulkan child window handling. This **should** fix (**mostly**) using wayland and vulkan for affinity photo.
It did seem a bit buggy still. For example its a bit flickery at times, and it still didn't work on wine's d3d11 and below handling.
It still doesn't work when using pure wayland for me, only XWAYLAND works for me on sway.
But if you run Photo with the vulkan renderer, and dxvk installed. It should work somewhat normally.
If you don't want to muck with regedit to set the renderer, you can just send the environment variable: `WINE_D3D_CONFIG="renderer=vulkan"`.
So to be clear, this branch includes:
- Remi Bernon's child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
- Remi Bernon's transparent window changes: https://gitlab.winehq.org/wine/wine/-/merge_requests/6025#note_75558
- Alexandros Frantzis's work for vulkan + gl child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/6107
- __avg__'s patches for hardware acceleration: https://github.com/oh-ok/wine-affinity-patches/tree/main
- My changes, with some of them reverted in place of __avg__'s.
I could not get hardware acceleration working on AMD. Although AMD's OpenCL functionality is a bit a of a cluster f*** with regards to ROCM and HIP and all that crap going on. @__avg__ if you have thoughts on this, I'm happy to hear them
The branch is named affinity-photo2-wine9.13 -- You can find it here: https://gitlab.winehq.org/ElementalWarrior/wine/-/tree/affinity-photo2-wine9.13?ref_type=heads

I created another branch. Updated off the most recent wine changes. It's the bleeding edge, so you may see issues in other in it.
I also included recent WIP patches for vulkan child window handling. This **should** fix (**mostly**) using wayland and vulkan for affinity photo.
It did seem a bit buggy still. For example its a bit flickery at times, and it still didn't work on wine's d3d11 and below handling.
It still doesn't work when using pure wayland for me, only XWAYLAND works for me on sway.
But if you run Photo with the vulkan renderer, and dxvk installed. It should work somewhat normally.
If you don't want to muck with regedit to set the renderer, you can just send the environment variable: `WINE_D3D_CONFIG="renderer=vulkan"`.
So to be clear, this branch includes:
- Remi Bernon's child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
- Remi Bernon's transparent window changes: https://gitlab.winehq.org/wine/wine/-/merge_requests/6025#note_75558
- Alexandros Frantzis's work for vulkan + gl child window handling: https://gitlab.winehq.org/wine/wine/-/merge_requests/6107
- __avg__'s patches for hardware acceleration: https://github.com/oh-ok/wine-affinity-patches/tree/main
- My changes, with some of them reverted in place of __avg__'s.
I could not get hardware acceleration working on AMD. Although AMD's OpenCL functionality is a bit a of a cluster f*** with regards to ROCM and HIP and all that crap going on. @__avg__ if you have thoughts on this, I'm happy to hear them
The branch is named affinity-photo2-wine9.13 -- You can find it here: https://gitlab.winehq.org/ElementalWarrior/wine/-/tree/affinity-photo2-wine9.13?ref_type=heads

Run winecfg and make sure you have your windows version set to something new, like windows 10

Run winecfg and make sure you have your windows version set to something new, like windows 10