Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C64Studio 7 on Linux using mono #56

Open
johanberntsson opened this issue Dec 20, 2021 · 19 comments
Open

C64Studio 7 on Linux using mono #56

johanberntsson opened this issue Dec 20, 2021 · 19 comments

Comments

@johanberntsson
Copy link

I've tried to get C64Studio running on Ubuntu 20.04. There are some copy problems in C64Studio.csproj, but they are easily fixed ny adding
cp $(TargetDir)C64Studio.exe $(SolutionDir)C64StudioRelease/$(TargetFileName)
cp $(TargetDir).dll $(SolutionDir)C64StudioRelease
rm -f "$(SolutionDir)C64StudioRelease/BASIC Dialects/
"
cp $(ProjectDir)BASIC?Dialects/* $(SolutionDir)C64StudioRelease/BASIC?Dialects

I can then build the program. However, when I run it I get

System.TypeInitializationException: The type initializer for 'GR.Image.DPIHandler' threw an exception. ---> System.EntryPointNotFoundException: GetDeviceCaps assembly: type: member:(null)
at (wrapper managed-to-native) GR.Image.DPIHandler.GetDeviceCaps(intptr,int)
at GR.Image.DPIHandler..cctor () [0x00029] in /home/johan/commodore/C64Studio/Common/Common/DPIHandler.cs:29
--- End of inner exception stack trace ---
at C64Studio.OutputDisplay..ctor () [0x0000d] in /home/johan/commodore/C64Studio/C64Studio/Documents/OutputDisplay.cs:13
at (wrapper remoting-invoke-with-check) C64Studio.OutputDisplay..ctor()
at C64Studio.MainForm..ctor (System.String[] args) [0x00000] in /home/johan/commodore/C64Studio/C64Studio/MainForm.cs:27
at (wrapper remoting-invoke-with-check) C64Studio.MainForm..ctor(string[])
at C64Studio.Program.Main (System.String[] args) [0x00023] in /home/johan/commodore/C64Studio/C64Studio/Program.cs:28

It seems to be some problem when calling gdi32.dll, which is mapped to libgdiplus.so.0 (see /etc/mono/config), and this library is installed. I don't know much about mono and can't get further, but it would be nice if it could be patched to work on Linux.

@GeorgRottensteiner
Copy link
Owner

GeorgRottensteiner commented Dec 20, 2021

Did you install the dotnet35 package? AFAIK this one was required when I tested it via PlayOnLinux in Ubuntu.

Edit: Just retested to be sure, 7.0 runs fine in Ubuntu for me.
If there is anything you need for me to lookup in that system, just ask. I'm not particularely fit with Linux systems.

@johanberntsson
Copy link
Author

johanberntsson commented Dec 21, 2021

I'm trying to get it to run on Linux itself, not through wine (which works). The problem seems to be that Xamarin/Mono have dropped support for older versions of .net on Linux, and the standard install is only for .net 4 and later. I found some instruction on how to install older versions but they are out of date and don't work any more. I don't know enough to fix this with a reasonable amount of effort.

@GeorgRottensteiner
Copy link
Owner

Ah, good catch. Some people are still using XP, and that's why I postponed updating the used .NET framework (still 3.5)
I think one of these days I have to update anyhow. Ideally I'll switch to .NET Core. That ought to solve this particular problem.

@johanberntsson
Copy link
Author

That sounds like a good idea. I'll try again when it happens.

@gcasa
Copy link

gcasa commented Dec 25, 2021

Does the same solution apply with macOS?

@GeorgRottensteiner
Copy link
Owner

I have absolutely no idea, but I guess that Mono works the same on different platforms.

@Beyley
Copy link

Beyley commented Apr 9, 2022

when building and running the latest master through latest Mono on Arch Linux, the program builds fine (after changing the post build task), but when running it seems to try to access a folder that only root can, not sure why though

i

@Beyley
Copy link

Beyley commented Apr 9, 2022

After fixing that problem by creating the folder with the right permissions, i was able to get far enough to see that a lot of code is directly talking with the native Windows APIs, first problem that came up was with the DPIHandler, which i just stubbed out, next was the FastImage class, which heavily uses the gdi32.dll native library, it might be possible to gut out the class and replace it with the cross platform SixLabors.ImageSharp or to System.Drawing though. Overall, most native imports arent that important, and it may be possible to replace all of them, as only ~60 native imports are used

Ah, good catch. Some people are still using XP, and that's why I postponed updating the used .NET framework (still 3.5) I think one of these days I have to update anyhow. Ideally I'll switch to .NET Core. That ought to solve this particular problem.

Switching to .NET Core, would unfortanately not fix the issue, as it still doesnt provide Linux versions of GDI or any other native windows APIs, aside from that, .NET core would also create a bigger issue, that being WinForms, as .NET core has 0 winforms support on linux, so if linux is a target, then you will have to stick with .net framework/mono

EDIT: Apparently mono has a gdi32.dll replacement, but not a user32.dll replacement, which is used by FastImage

EDIT2: i managed to get it semi-running, but its crashing on FastColoredTextBox.cs due to Imm32.dll access
i

@GeorgRottensteiner
Copy link
Owner

Yeah, I did some ugly PInvoke stuff with FastImage. Back when I introduced it I had performance issues and huge delays with System.Drawing. I'll see if I can fix it up now, should be doable.
Imm32.dll is a problem though, that's Windows' input method manager for special keyboard layout methods. As I see it's only used in a few places; I could probably conditionally keep it out when compiling via Mono.

@Beyley
Copy link

Beyley commented Apr 9, 2022

Yeah, I did some ugly PInvoke stuff with FastImage. Back when I introduced it I had performance issues and huge delays with System.Drawing. I'll see if I can fix it up now, should be doable. Imm32.dll is a problem though, that's Windows' input method manager for special keyboard layout methods. As I see it's only used in a few places; I could probably conditionally keep it out when compiling via Mono.

I believe in Mono, the most popular IMEs do "just work" with the basic Mono WinForms controls, so yeah conditionally skipping the Imm32.dll calls on non-windows platforms would work

@Beyley
Copy link

Beyley commented Apr 9, 2022

Also, if you replace the property group at the end of C64Studio.csproj with

  <PropertyGroup>
    <PostBuildEvent Condition="'$(OS)' == 'Windows_NT' ">copy "$(TargetDir)C64Studio.exe" "$(SolutionDir)C64StudioRelease\$(TargetFileName)"
      copy "$(TargetDir)*.dll" "$(SolutionDir)C64StudioRelease"
      del "$(SolutionDir)C64StudioRelease\BASIC Dialects\*.*" /Q
      copy "$(ProjectDir)BASIC Dialects\*.*" "$(SolutionDir)C64StudioRelease\BASIC Dialects"</PostBuildEvent>
    <PostBuildEvent Condition="'$(OS)' == 'Unix' ">cp $(TargetDir)C64Studio.exe $(SolutionDir)C64StudioRelease/$(TargetFileName)
      cp $(TargetDir).dll $(SolutionDir)C64StudioRelease
      rm -f "$(SolutionDir)C64StudioRelease/BASIC Dialects/"
      cp $(ProjectDir)BASIC?Dialects/* $(SolutionDir)C64StudioRelease/BASIC?Dialects</PostBuildEvent>
  </PropertyGroup>

ittl fix the builds on linux

GeorgRottensteiner added a commit that referenced this issue Apr 9, 2022
        -> deactivate PInvoking imm32.dll for Mono builds
        -> modify post build event to work for Unix'
@Beyley
Copy link

Beyley commented Apr 9, 2022

hmmm it seems that compile time constant isnt working for me
i

and also, that code doesnt compile anyway, as the top func is extern yet has a body, which produces a compile error

@Beyley
Copy link

Beyley commented Apr 9, 2022

After gutting out the caret funcs in FastColoredTextBox, i was able to get it fully booting on my local fork which just entirely guts fastimage and related code, so all thats left is to remove FastImage usage, and it should hopefully work on linux after that
(i cant test too much here as a lot requires fastimage so this is really barebones)
i

@GeorgRottensteiner
Copy link
Owner

Nice! It'll take a while to replace FastImage.
Did you check if the cursor is still working in the editor control? The caret is the blinking cursor, that is crucial.

@Beyley
Copy link

Beyley commented Apr 10, 2022

Nice! It'll take a while to replace FastImage. Did you check if the cursor is still working in the editor control? The caret is the blinking cursor, that is crucial.

i

The position seems wrong, but other then that, it seems to work (albeit it blinks very slowly), i wonder if the position is wrong due to the font?

EDIT: Its actually decently usable, the caret position is just slightly too far right, but aside from that it seems to follow text properly

@Beyley
Copy link

Beyley commented Apr 10, 2022

One problem which is a little more important: the keys always activate the top bar's shortcuts , so letters like D are just untypable

@GeorgRottensteiner
Copy link
Owner

The shortcut issue is weird. I wonder if a SetFocus call got missing?

@Beyley
Copy link

Beyley commented Apr 11, 2022

The shortcut issue is weird. I wonder if a SetFocus call got missing?

Its possible i had accidentally stripped it out when mass deleting code that references FastImage

@bugjacobs
Copy link

Please keep hacking on this as I really want to use it on Linux with the least bit of fuss :-D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants