Runnig on Windows 10 and detecting Mono installation

[tenko]

Interesting project! I like the practical changed done to the original Oberon version. A remarkable powerful and simple language. It will be interesting to follow this project.

I was testing on Windows 10 and had to make a small modification for the Mono exe to run:

MonoEngine.cpp:

@@ -199,14 +199,18 @@ void Engine::run(const QString& assembly, const QStringList& args)
     if( workDir.isEmpty() )
         workDir = monoDir;
     d_proc->setWorkingDirectory(workDir);
+#ifdef Q_OS_WIN
+    d_proc->setProgram( QDir(monoDir).absoluteFilePath("mono.exe"));
+#else
     d_proc->setProgram( QDir(monoDir).absoluteFilePath("mono"));
+#endif

I also made a small change in order to detect the Mono installation if available:

ObxIde2.cpp:

@@ -32,6 +32,7 @@
 #include <QStandardPaths>
+#include <QSettings>

 bool Ide::checkEngine(bool withFastasm)
 {
+#ifdef Q_OS_WIN
+    QSettings s("HKEY_LOCAL_MACHINE\\SOFTWARE\\Mono", QSettings::NativeFormat);
+    if (s.contains("SdkInstallRoot")) {
+        d_eng->setMonoDir(s.value("SdkInstallRoot").toString() + "\\bin");
+    } else {
+        d_eng->setMonoDir(QApplication::applicationDirPath() + "\\mono");
+    }
+    return true;
+#else

This will look in the Windows registery for information regarding the installation and use this if available. This was tested with Mono version 6.12.0.107 Older version will probably work, but are not tested.

In the future I will learn to make proper pull request and save you the hassle of paste and hand editing.

[rochus-keller]

Thanks for the feedback. Have you seen the precompiled Windows executable (https://github.com/rochus-keller/Oberon#binary-versions)? It works well without the changes you propose. Note that QProcess::setProgram doesn't need the ".exe" suffix, but just the application name, and Qt makes sure it is properly translated according to each platform's rules.

You also don't have to apply platform specific paths in QSettings.

Mono is meant as an (invisible) integrated part of the IDE. The IDE by intention doesn't look anywhere but in the mono subdirectory relative to the executable. The binary deployment includes the two files from Mono 5 required to operate the IDE: mono.exe (i.e. a renamed mono-sgen.exe and mono-sgen.dll) and mscorlib.dll; these are the minimum files to use Mono; .NET compatibility of Oberon+ is not intended; Mono is only used during development and debugging. The resulting application will be the optimized executable compiled from the exported C code (which is platform independent and even could run on embedded systems); the C generator is WIP; current tests demonstrate an overall performance speed-up factor ~ 2 compared to the same application run on Mono.

[tenko]

Hi,

I had trouble downloading the precompiled Windows executable. Pressing on the link does not work in Chrome on Windows 10. I did manage to use the CLI wget program later though.

In the mean time I compiled the application my self, and wanted to use the standard Mono installation. It seems to me if not .exe is set in QProcess::setProgram, Qt will mangle up the Windows path in a strange way.

I now see your intent is distribute a small part of Mono only as C is the final target. Feel free to close this issue.

PS! Have you looked into the Zig language which has solved the problem with cross compilation in an elegant way (Also C code)? Zig cross-compiling Zig compiler is also a C compiler This seems to be maturing fast now and picking up interest and could be utilized to support many targets out of the box.

[rochus-keller]

You can also use the Mono assemblies in the deployment if need be; the full language extent is supposed to be supported by both the Mono/CIL code generator as well as the C generator (including e.g. the FFI). In case of a Linux based embedded system even remote debugging based on the Mono debugger protocol could be realized.

I have a look at the Zig language (and other interesting candidates such as Nim, D or Crystal) all other few months; Zig has some interesting concepts, but it is getting more and more complex everytime I look at it (which applies to the other candidates as well). The idea of Oberon+ is to be as simple as possible and thus an antithesis to complex languages such as C++ or the other ones mentioned; if I need more expressibility than Oberon+ offers I already have C++; whether and to which extent Oberon+ is useful for critical real-world projects is subject to my future projects.

[tenko]

Thanks for the elaborate reply. I will look into Mono. Earlier I have thought of this as a Desktop centric solution.

Agree with your sentiment regarding complexity. It seem to be ever increasing (sort of like entropy in the Universe) Commercial software still have decades old bugs etc. At some point we will reach an inflection point where the current status quo is unattainable. I wonder if the latest uptake to cloud solutions everywhere are actually sustainable.

"As simple as practical possible" languages like Oberon and derivates are an obvious solution, but hardware also needs to become simpler (ref. bugs in CPU etc)

I was thinking when Zig matures, it could possible be distributed with the IDE to support cross platform C compilation out of the box in the same way Mono is distributed. Just a thought.

[rochus-keller]

Welcome. Mono is just a CLI implementation according to the ECMA-355 and ISO 23271. The CLI and the CLR/CIL are platform independent (i.e. run on each platform where a CLR is available, once compiled). It's in no way related to a GUI or desktop (in contrast to the .Net framework built on top of CLI). You can compare Mono with CoreCLR or the old .NET CLR. As it turned out Mono has a very good optimizing JIT and some other useful features like the soft debugger protocol. There are voices claiming that Mono is much slower than CoreCLR, but I made measurements which demonstrate that this is not true (see https://www.quora.com/Is-the-Mono-CLR-really-slower-than-CoreCLR/answer/Rochus-Keller).

Zig heavily depends on LLVM, which is an impressive technology for one part, but at the same time a complex heavyweight. I first planned to build an LLVM backend for Oberon+, but instead decided to implement a C generator instead, by which eventually the same performance can be achieved, but only depending on a C99 compiler.