For those guys porting Spring...
Moderator: Moderators
- Stealth870
- Posts: 166
- Joined: 13 Sep 2004, 00:25
For those guys porting Spring...
http://www.eweek.com/article2/0,1759,1819422,00.asp
Apparently hits allows the Visual Studio .NET stuff to be coded in Linux now. I think that's what the client is built on right? Just to let yall know if its of any help :)
Apparently hits allows the Visual Studio .NET stuff to be coded in Linux now. I think that's what the client is built on right? Just to let yall know if its of any help :)
I've been playing a bit with Mono. I just tried to build the SpringClient on Mono 1.1.7 and using the very latest System.Windows.Forms.dll (from http://mwf.mono-project.com) only the RichTextBox throws errors. It compiled fine when I replaced them with a normal TextBox. However I am working on the resources right now as Mono seems to have a bit different naming scheme. Besides that I don't know the behaviour of the Microsoft.Win32.Registry and you would have to port the C++ dlls in SpringClient/Utilty to linux.
Hey, cool. I already mostly ported /Utility, available at https://lolut.utbm.info/svn/taspring_li ... t/Utility/SeaEagle1 wrote:I've been playing a bit with Mono. I just tried to build the SpringClient on Mono 1.1.7 and using the very latest System.Windows.Forms.dll (from http://mwf.mono-project.com) only the RichTextBox throws errors. It compiled fine when I replaced them with a normal TextBox. However I am working on the resources right now as Mono seems to have a bit different naming scheme. Besides that I don't know the behaviour of the Microsoft.Win32.Registry and you would have to port the C++ dlls in SpringClient/Utilty to linux.
Also, go ahead and ignore anything registry... That's what we are doing in the rest of the program.
Mono builds an Intermediate Language .exe, just like Java builds bytecode .class files. It gets compiled to machinecode the first time you run it by either the MS .NET framework or Mono ( or another Mono-like project ). You do have to run it like ">mono SpringClient.exe" because linux doesn't call mono "under the hood" like Windows does with the .NET framework. efbie is right, MS probably just called it .exe's and .dll's so the average Windows user would feel comfortable, but they're more comparable to Java's .class files than C++ .exe's.
I'm ignoring the registry calls right now too, but they're there for a reason, to store config settings, that I might need to implement another way, through some XML file or something.
Edit:
I just found out that .resx resources need to be converted for Mono, so now it's running fair enough to provide you with a screenshot...
Edit II:
And please whoever wrote this thing, use "/" instead of " \\" in your paths next time, Windows doesn't care what you use, but linux really does not like "\\"...
I'm ignoring the registry calls right now too, but they're there for a reason, to store config settings, that I might need to implement another way, through some XML file or something.
Edit:
I just found out that .resx resources need to be converted for Mono, so now it's running fair enough to provide you with a screenshot...
Edit II:
And please whoever wrote this thing, use "/" instead of " \\" in your paths next time, Windows doesn't care what you use, but linux really does not like "\\"...
Is that you connected to the real Spring server? What do you do about loading dll's(curiosity's sake)? If the code speaks for itself, go ahead and send me patches!SeaEagle1 wrote:I'm ignoring the registry calls right now too, but they're there for a reason, to store config settings, that I might need to implement another way, through some XML file or something.
Edit:
I just found out that .resx resources need to be converted for Mono, so now it's running fair enough to provide you with a screenshot...
That's me connected to the real Spring server yes... I was even able to do some chatting I hope though that Mono will soon come with a new version as I needed to hack around some NotImplemented Exceptions from the Winforms.
C# can import native .dll or .so files with PInvoke (those [DllImport ...] lines), but I haven't looked into them yet.
C# can import native .dll or .so files with PInvoke (those [DllImport ...] lines), but I haven't looked into them yet.
These are the changes I made so far.
I'm now a bit stuck as I need to import the ported c++ libs and your libUtility doesn't really work yet...
Mono-INFO: DllImport error loading library './libUtility.so: undefined symbol: _ZN10CSunParserC1Ev'.
I don't know if you can do something with that . Also for the actual starting of the game we'll need a ported unitsync.dll (and game ofcourse). And I don't know what the progress is on a c++ client? It's quite useless if we're trying to adapt the .NET client when someone is also writing another port.
I'm now a bit stuck as I need to import the ported c++ libs and your libUtility doesn't really work yet...
Mono-INFO: DllImport error loading library './libUtility.so: undefined symbol: _ZN10CSunParserC1Ev'.
I don't know if you can do something with that . Also for the actual starting of the game we'll need a ported unitsync.dll (and game ofcourse). And I don't know what the progress is on a c++ client? It's quite useless if we're trying to adapt the .NET client when someone is also writing another port.
Well, the client that me and coryrc are writing won't be done for a while yet. We are just getting done designing the GUI, but the coding hasn't actually started yet. I think coryrc thinks that if we can get a working mono port, then people can play it in Linux while we wait for the real thing to be done.