RunUO Community
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
Possibly the biggest announcement ever for RunUO!
- Thread starter Ryan
- Start date
Mark stated the fact that RunUO has the code to support non-windows file(s) files ie _lread which instead will use the Mono support file(s).
Considering you don't have the source, that information would be pointless at this point. I am sure once its released somebody will look at the code and figure how to compile it with the mono flag.
Need I might remind you the policy about sharing the binaries of RunUO. That rule has not changed, and I hope will not change even after the release.
What Ryan meant was that Mono doesn't support basic things that the .NET Framework does. Its not a good idea to work around those problems and get rid of suppport like reflection just to make it work on Mono.
Of course its been a good amount of time since its been tested, and at the time of the last release Mono had a problem with reflection.
I didn't state that exactly, I stated there is support already for it, but again Mono has problems with the very basic .NET Framework classes. Read what I stated again, what I said was there is support for Mono, it still doesn't mean it will work.
I am trying not to speak for the Development Team, I can only share what I just learned yesterday from Mark regarding this issue. I can tell you, your still not allowed to decompile or distrubute a version of RunUO yourself. Till that changes, you would breaking the rules, and of course a moderator could do something about your access to this forum.
Considering you don't have the source, that information would be pointless at this point. I am sure once its released somebody will look at the code and figure how to compile it with the mono flag.
Need I might remind you the policy about sharing the binaries of RunUO. That rule has not changed, and I hope will not change even after the release.
What Ryan meant was that Mono doesn't support basic things that the .NET Framework does. Its not a good idea to work around those problems and get rid of suppport like reflection just to make it work on Mono.
Of course its been a good amount of time since its been tested, and at the time of the last release Mono had a problem with reflection.
I didn't state that exactly, I stated there is support already for it, but again Mono has problems with the very basic .NET Framework classes. Read what I stated again, what I said was there is support for Mono, it still doesn't mean it will work.
I am trying not to speak for the Development Team, I can only share what I just learned yesterday from Mark regarding this issue. I can tell you, your still not allowed to decompile or distrubute a version of RunUO yourself. Till that changes, you would breaking the rules, and of course a moderator could do something about your access to this forum.
Just to give my 2 cents to this Mono/Linux discussion... Mono is a good framework, although there are mani porting problems from Windows to Linux... obviusly since RunUO uses only .NET classes, we could say "it's Mono's fault"... well... that's not exactly true... the problem is many methods used by framework are directly imported from C++ dlls... since (obviusly) Microsoft didn't want to lose all the work done till now, some classes are C# porting of existing C++ classes... others call directly the C++ dll... this can be easly seen in GDI+ libraries, wich classes are too etherogeneous to be built at the same time (and it's quite frustrating)... moreover, many methods are wrappers to WinAPIs (sometimes it's difficult to port a OS API to another OS)... that's why Mono can't match perfectly with RunUO at this time...
Since I could be wrong or inexact about Mono/.NET, plz, anyone feel free to correct me, I'll be glad for any correction!
At least, ss many others said, I think "RunUO on Linux" is not something that should interest devs... anyone will be able (when sources will be released) to modify RunUO to try something... moreover this discussion is a bit menaingless, since no one except devs can/should have tried to compile RunUO under Linux
Since I could be wrong or inexact about Mono/.NET, plz, anyone feel free to correct me, I'll be glad for any correction!
At least, ss many others said, I think "RunUO on Linux" is not something that should interest devs... anyone will be able (when sources will be released) to modify RunUO to try something... moreover this discussion is a bit menaingless, since no one except devs can/should have tried to compile RunUO under Linux
Quantos
Lord
Kethinov said:
The bad programming, which is probably better simply called an unfinished system, is Mono, NOT the RunUO core. What they mean is that RunUO already has what is needed for Mono to run it, when Mono is properly finished.
It would be a very bad practise to modify RunUO to work on a flawed Mono. The best approach, as I'm sure anyone with any skill at programming would agree, would be to complete Mono properly, and then run RunUO on it.
Since I am only a Iron Worker, I can't beleive that I understand this and many 'programmers' don't understand it. I'm not saying, however, that you are one of those 'programmers'.
Quantos
Lord
Vidi said:
Face it though, we both know that there will be people that will try to make some 'l33t' modifications to the core. There will also be people that will attempt to modify the core so that it will run on Mono. I am greatly relieved that we won't be exposed to most of that, and that Ryan will attempt to protect us from those childish attempts. The truly sad thing, however, is that there will be people that will try to demand support for those core files.
There are a couple of positive notes, however. One is that the team we have here will continue to put out quality releases that we can use, and our player base will continue to enjoy playing on. The other is that people with the talent, and the skill can use the open source core as a sample to develop emulators for other games that can be played on line with no charge, and with a huge capacity for modifications.
As great as my misgivings were at the begining of this thread, and are now, the capacity for growth and new potential outside of RunUO is absolutely astounding.
Bladewise for the most part I would say your mistaken, for the simple fact .NET Framework does not work like anything else.
Mono is suppose to support it, within the stated systems it claims to support, therefore a application written in windows is suppose to work the same if your using Mono.
Of course because RunUO uses windows files to do some of the things it does, over time they have added support for both .NET Framework within a windows system and the Mono .NET Framework within the support systems it supports.
In that aspect your wrong, stating that .NET Framework is ported from C++, which might be the case in some aspects but it certainly isn't the origin of the problem.
If I miss understood something you said, feel free to go to make it more clear. Although you do get the general idea/problem with the current issue of Mono support.
Mono is suppose to support it, within the stated systems it claims to support, therefore a application written in windows is suppose to work the same if your using Mono.
Of course because RunUO uses windows files to do some of the things it does, over time they have added support for both .NET Framework within a windows system and the Mono .NET Framework within the support systems it supports.
In that aspect your wrong, stating that .NET Framework is ported from C++, which might be the case in some aspects but it certainly isn't the origin of the problem.
If I miss understood something you said, feel free to go to make it more clear. Although you do get the general idea/problem with the current issue of Mono support.
I really think that right now, the fault cannot rest on Microsoft .Net Framework nor can it rest on RunUO's (except if you consider DllImport calls of say _lread).
I admit there is an abondant use of unmanaged code hidden under the hood of the Microsoft .Net framework yet, this only means guys at Mono will have more work to do over what is working and how it will.
Personally, my last try with RunUO under Mono resulted in a problem with serialization, but as of right now, it really seems like everyone has different problem with Mono. Since Mono is based on the Microsoft.Net Framework, it is normal and completely logical to assume it is Mono's fault.
Nobody is bringing any new point in about Mono and RunUO.
Nobody can REALLY try RunUO under Mono
Conclusion: Everyone can only throw hypothesis about this.
(Exclude RunUO developers from these affirmations)
So I'll repeat again, there is no point in talking about that right now.
Wait for the RunUO Core source release and THEN you will have all the evidence to kill yourself over the Linux argument.
I admit there is an abondant use of unmanaged code hidden under the hood of the Microsoft .Net framework yet, this only means guys at Mono will have more work to do over what is working and how it will.
Personally, my last try with RunUO under Mono resulted in a problem with serialization, but as of right now, it really seems like everyone has different problem with Mono. Since Mono is based on the Microsoft.Net Framework, it is normal and completely logical to assume it is Mono's fault.
Nobody is bringing any new point in about Mono and RunUO.
Nobody can REALLY try RunUO under Mono
Conclusion: Everyone can only throw hypothesis about this.
(Exclude RunUO developers from these affirmations)
So I'll repeat again, there is no point in talking about that right now.
Wait for the RunUO Core source release and THEN you will have all the evidence to kill yourself over the Linux argument.
Quantos
Lord
I'm not sure what your experience and knowledge with Linux is. With Linux when you 'install' an application you don't receive a binary installer that you run, and it does all of the work for you.BladeWise said:At least, ss many others said, I think "RunUO on Linux" is not something that should interest devs... anyone will be able (when sources will be released) to modify RunUO to try something... moreover this discussion is a bit menaingless, since no one except devs can/should have tried to compile RunUO under Linux
What you get is a package that you compile with the corresponding libraries to make it run properly, this is what makes applications so stable on Linux. As a result of this method, each application will run in it's own thread(the way that I understand it works).
So in essence anybody who attempts to use RunUO on Mono is actually required to compile RunUo.
To try and give you a little bit more information, with Linux it is actually even standard practice to compile a custom version of the Linux kernel based on the hardware and software configuration of each system.
Most Linux users actually have multiple kernel configurations available on a single system, and they can select the different kernels depending on what they will be doing.
Again, this is not the correct way to approach or solve the RunUO/Mono issue. This is actually almost like ripping apart a part of your house and rebuilding it, just because a lightbulb is burnt out in another portion of the house. It doesn't fix the light not working, but makes you look busy all the same.BladeWise said:
This example may seem farfetched, and incorrect, but in fact is very close to what most of these people are suggesting when they talk about modifying the RunUO core so that it will function on Mono.
Quantos
Lord
ZixThree said:
A very valid point, but as long as people keep bringing up the suggestion to modify the RunUO core to function under Mono, we are obliged to try to give them understanding into why that suggestion is flawed. That is the responsibility of knowledge, to share it with others.
A great man said 'there is much responsibility that accompanies much knowledge'.
FrostBarge
Wanderer
I had actully messed around with Linux last semester in school and all got to say is, Why?
Why would you mess with Linux anyways from what I had experianced is it uses old dinosaur like system for code to even work with it. I have even went farther in my text to see what the advantages are but all that I am seeing is pretty much nothing. I have heard that they make a nice server OS but outside of that I see nothing spactacular about it.
Why would you mess with Linux anyways from what I had experianced is it uses old dinosaur like system for code to even work with it. I have even went farther in my text to see what the advantages are but all that I am seeing is pretty much nothing. I have heard that they make a nice server OS but outside of that I see nothing spactacular about it.
Quantos said:
I don't want to blow up your ballon, but...
- There are numerous programs running on linux that do not distribute their sources.
- There is technicaly no thread under Linux reign, only processes (I know there are packages for threads but still it isn't native).
- Compilation under Linux is never mandatory, most packages are offered in two forms, sources and binaries (yes, even on Linux).
- Kernel modification are not always necessary and I don't really know why you would want multiple kernel. I wouldn't change a server kernel everyday for the fun of it or each time I need to backup something.
Quantos said:
I think your parallel between RunUO/Mono issue is flawed.
I would better see an electric outlet... You have a electric toaster(or whatever) you want to plug-in, it has an unknown plug type, but you have an adaptor for American standard plug. You are in the US or Canada, all is good, same electric outlet type everywhere. You go in Europe, my bad, different outlet. You just change the adaptor for your toaster, it won't change the toaster functionality, but if the adaptor isn't working correctly (doesn't give the right voltage for one), it can seriously mess things. Then your toaster wouldn't work the way it's supposed to even with the adaptor unless you get another version of the adaptor that works (or another adaptor altogether).
FrostBarge said:I had actully messed around with Linux last semester in school and all got to say is, Why?
Why would you mess with Linux anyways from what I had experianced is it uses old dinosaur like system for code to even work with it. I have even went farther in my text to see what the advantages are but all that I am seeing is pretty much nothing. I have heard that they make a nice server OS but outside of that I see nothing spactacular about it.
There hasn't always been Windows Server. If you are old enough to remember de Windows 3.1 and Windows 9x days, you can remember the numerous blue screen and crashes. Two unacceptable consequence of using Windows that administrator could not afford, thus why Windows had a bad reputation for so long for hosting servers.
The Server situation greatly changed over the years for Windows product, but still numerous people do not give actual credit to Windows due in part for older version bad reputation and in part because of Windows monopolistic scheme. Some other people have some other reason, but basically Linux is considered an alternative. I am not saying right now that Linux or Windows is the better, first because I don't care and second because they are two products with pros and cons that are better depending on the situation.
Important note: this isn't supposed to be a complete explanation (nor an accurate one)
To Phantom:
Just to clarify what I said above (sorry Ryan for another semi-OT post, will be obviusly the last... I apologize again
)
Sorry for choosing wrong terms, I didn't mean .NET is a "porting" from C++, I meant .NET framework (developed for windows machines) makes intense use of Windows API in it's most important parts (i.e. reflection, threads, sockets...) and sometimes uses old functions (loaded by C++ libs mostly) that are OS-dependant (because are API-dependant)... my fault for not being clear enough
Moreover, since Mono pretends to be portable (in this case is correct to speak about "portable") on different OS (Linux, MacOS, Windows...), Mono devs must find a "common" way (or a compromize) to do that... in this sense, framework is simpler than Mono, 'couse .NET framework can work only on Windows... anyway, stop with this Mono/Linux talking...
I apologize again for this post with Ryan (thnx again for realeasing RunUO sources!!!!) and everyone else (maybe not interested)...
Just to clarify what I said above (sorry Ryan for another semi-OT post, will be obviusly the last... I apologize again
)You are absolutely right!Phantom said:
Sorry for choosing wrong terms, I didn't mean .NET is a "porting" from C++, I meant .NET framework (developed for windows machines) makes intense use of Windows API in it's most important parts (i.e. reflection, threads, sockets...) and sometimes uses old functions (loaded by C++ libs mostly) that are OS-dependant (because are API-dependant)... my fault for not being clear enough
Moreover, since Mono pretends to be portable (in this case is correct to speak about "portable") on different OS (Linux, MacOS, Windows...), Mono devs must find a "common" way (or a compromize) to do that... in this sense, framework is simpler than Mono, 'couse .NET framework can work only on Windows... anyway, stop with this Mono/Linux talking...
I apologize again for this post with Ryan (thnx again for realeasing RunUO sources!!!!) and everyone else (maybe not interested)...
ZixThree said:I don't want to blow up your ballon, but...
- There are numerous programs running on linux that do not distribute their sources.
- There is technicaly no thread under Linux reign, only processes (I know there are packages for threads but still it isn't native).
- Compilation under Linux is never mandatory, most packages are offered in two forms, sources and binaries (yes, even on Linux).
- Kernel modification are not always necessary and I don't really know why you would want multiple kernel. I wouldn't change a server kernel everyday for the fun of it or each time I need to backup something.
Being that there are vulnerabilities found in kernels, it is viable to patch those kernels so the holes can be fixed. Just like today, there was a hole found in the kernel that lets a local user gain root privs. That is why you upgrade kernels.
Case in point... http://isec.pl/vulnerabilities/isec-0021-uselib.txt
