25 Jan 2020 @ 11:16 PM 

I don’t get why Linux is associated with programming so heavily. Or why it is said to be "good for programmers".

Now, I have some personal systems running Linux, and I’m relatively familiar with it. It’s a fine system. But I still don’t get why people associate Linux with Programming. Or rather why people make that connotation positively. I can’t even use, (realistically) those systems for my work!

I can think of four main reasons. One is that you have GCC as well as any number of other compilers built in to most linux distributions or at least easily accessible. Source control systems are usually developed for Linux and hell Git, one of the most popular, was developed originally for the Linux Kernel.

The second reason I can think is that it takes a programmer to actually customize it properly. Which isn’t strictly speaking a bad thing, but for all the problems people claim of Windows, many problems can be fixed in exactly the same way. People often talk about customizing their Linux distributions by programming new components, and then say "you can’t do that on Windows"… but that doesn’t make sense. Of course you can! I’ve written software specifically to customize my Windows experience on my Windows systems just as I’ve done the same for Linux. When Windows 10’s Network connection “foldout” was for lack of a better word, awful, I took it upon myself to solve my issue myself and created my own program that allowed connecting to networks via the Notification area. It uses rasphone, but what I’ve found is that for some reason it is more reliable than the built-in Windows interface.

Another angle is that perhaps “programmer” nowadays is often used to refer to “web developer”, via the development of web ‘applications’ and websites, for which Linux makes perfect sense since it is the basis of the most common LAMP web stack that is found/supported on most VPS systems, and can be administered via SSH as well quite easily. It’s also common to use things like Postfix and dovecot for managing mail, and, it can all be set up for only the cost of hardware. For that it certainly makes sense to work on Linux rather than try to test your Web application/software on Windows, because if you use Linux your testing environment will be the same as the one you eventually deploy it too.

One contributing factor I think is that a lot of the best programmers in the world have used nix like environments. However, Programming- like most "STEM", is full of hubris, so even though 99% of programmers can’t; be the 1%, we all seem to think we are top shelf product. Too many programmers don’t even consider that maybe the top 1% are people that are literally smarter than them, They think instead they must have hit some kind of “glass ceiling” because of their toolset or their OS. Some of us are so used to being "top of our class" or the "smartest one in the room" or rockstar programmers at small companies that we forget that in a larger scope, we are merely average and a lot of programmers/software developers cannot accept that. Clearly, It must SIMPLY be the toolset these top 1% use. So they start mimicking some of the best programmers, people like Paul Graham. They read his essays and see him making negative remarks about "mediocre" developers and the "masses" who use "Visual Blub" (Visual Studio") And they laugh, and go "haha, so true!" or repeat quotes to others, with zero self awareness. They start writing programs in Lisp, but their expressiveness is dreadful, and they still don’t even know what a cons pair is, but they’ll pretend if you ask them. They start writing code in eMacs or VI. But they can’t figure out why they aren’t shooting to the top. Could it be that they aren’t as smart as somebody else? "No…. no that isn’t true. That’s impossible!"

Emulating those top 1% by using the same toolsets as them doesn’t magically make you a better programmer. It’s equivalent to finding out they all drive say Toyota’s and figuring that if you drive a Toyota that you will become a good programmer. You don’t become a good programmer by following others; Those top 1% that people try to emulate didn’t follow anybody else to reach there, they followed their own path. Perhaps all those paths lead to *nix. Perhaps not. But you aren’t going to become a good programmer by simply taking a shortcut to the end of the path because what actually makes you more proficient at software development and programming is the journey not the final destination.

Posted By: BC_Programming
Last Edit: 31 Jan 2020 @ 02:36 AM

EmailPermalinkComments (0)
Tags: , ,
Categories: Linux, Programming
 19 Oct 2019 @ 3:22 PM 

Over the last few years – more than a decade, really – it seems that, somehow, *nix- and Linux in particular, has been tagged as being some sort of OS ideal. It’s often been cited as a "programmers OS" and I’ve seen claims that WIn32 is terrible, and people would take the "Linux API" over it anyday. That is a verbatim quote as well.

However, I’ve thought about it some and after some rather mixed experiences trying to develop software for Linux I think I feel something of the opposite. Perhaps, in some ways, it really depends what you learned first.

One of the advantages of a Linux-based (or to some extent, UNIX-based) system is there is a lot of compartmentalization. The user has a number of choices and these choices will affect what is available to the applications.

I’d say that generally, The closest thing to a "Linux API" that applications utilize would probably just be the Linux Kernel userspace API.

Beyond that, though, as a developer, you have to start making choices.

Since the user can swap out different parts, outside of the Linux Kernel userspace API, pretty much nothing is really "standardized". Truth be told most of that kernel userspace API isn’t even used directly by applications- usually they get utilized through function calls to the C Standard library.

The Win32 API has much more breadth but tends to be more "simple", which tends to make using it more complicated. Since it’s a C API, you aren’t going to be passing around OO instances or interfaces; typically more complicated functions accept a struct. Hard to do much better than that with a C API.

However, with Windows, every Window is created with CreateWindowEx() or CreateWindow(). No exceptions. None. Even UWP Windows use CreateWindow() and have registered Window classes. Even if perhaps it’s not the most pleasant base to look at at least there is some certainty that, on Windows, everything is dealt with at that level and with those functions.

With Linux, because of the choices, things get more complicated. Since so many parts are interchangable, you can’t strictly call most of what is made available and used by applications a "Linux API" since it isn’t going to exist on many distributions. X11, for example, is available most of the time, but there are still Linux distributions that use Wayland or Mir. Even using just X11, it only defines the very basic functions- It’s a rare piece of software that actually interacts directly with X11 via it’s server protocol, usually software is going to use a programming interface instead. But which one? For X11 you’ve got Xlib or xcb. Which is better? I dunno. Which is standard? Neither. And then once you get down to it you find that it only actually provides the very basics- what you really need are X11 extensions. X11 is really only designed to be built on top of, with a Desktop Environment.

Each Desktop environment provides it’s own Programming Interface. Gnome as I recall uses "dbus"; KDE uses- what was it? kdetool? Both of these are CLI software that other programs are supposed to call to interact with the desktop environment. I’m actually not 100% on this but all the docs I’ve found seem to suggest that at the lowest level aspects of the desktop environment is handled through calls to those CLI tools.

So at this point our UI API consists of calling a CLI application which interacts with a desktop environment which utilizes X11 (or other supported GUI endpoints) to show a window on screen.

How many software applications are built by directly interacting with and calling these CLI application endpoints? Not many- they are really only useful for one-off tasks.

Now you get to the real UI "API"; the UI toolkits. Things like GTK+ or Qt. These abstract yet again and more or less provide a function-based, C-style API for UI interaction. Which, yes- accepts pointers to structs which themselves often have pointers to other structs, making the Win32 API criticism that some make rather ironic. I think it may arise when those raising the criticism are using GTK+ through specific language bindings, which typically make those C Bindings more pleasant- typically with some sort of OO. Now, you have to choose your toolkit carefully. Code written in GTK+ can’t simply be recompiled to work with Qt, for example. And different UI toolkits have different available language bindings as well as different supported UI endpoints. Many of them actually support Windows as well, which is a nice bonus. usually they can be made to look rather platform native- also a great benefit.

It seems, however, that a lot of people who raise greivance with Win32 aren’t comparing it to the direct equivalents on Linux. Instead they are perhaps looking at Python GTK+ bindings and comparing it to interacting directly with the Win32 API. It should really be no surprise that the Python GTK+ Bindings are better; that’s several layers higher than the Win32 API. It’s like comparing Windows Forms to X11’s server protocol, and claiming Windows is better.

Interestingly, over the years, I’ve come to have a slight distaste for Linux for some of the same reasons that everybody seems to love about it, which is how it was modelled so heavily on UNIX.

Just in the last few years the amount of people who seem to be flocking to OS X or Linux and holding up their UNIX origins (obviously more so OSX than Linux, strictly speaking) as if that somehow stands on it’s own absolutely boggles my mind. I can’t stand much about the UNIX design or philosophy. I don’t know why it is so constantly held up as some superior OS design.

And don’t think I’m comparing it to Windows- or heaven forbid, MS-DOS here. Those don’t even enter this consideration at this point- If anything can be said it’s that Windows wasn’t even a proper competitor until Windows NT anyway, and even then, Windows NT’s kernel definitely had a lot of hardware capability and experience to build off that UNIX never had in the 70’s- specifically, a lot of concepts were adopted from some of the contemporaries that UNIX competed against.

IMO, ITS and MULTICS were both far better designed, engineered, and constructed than any UNIX was. And yet they faded into obscurity. often People point at Windows and say "The worst seems to get the most popular!" But if anything UNIX is the best example of that. So now we’re stuck with people who think the best OS design is one where the the shell is responsible for wildcard expansion and the underlying scheduler is non-preemptive. I wouldn’t be surprised if the UNIX interrupt-during-syscall issue was still present, and instead of re-entering the syscall it returned an error code, making it the application’s responsibility to check for the error and re-enter the syscall.

It seems to me that one of the axioms behind many of the proclamations that "*nix is better designed" seems to be based on definitions of "better designed" that correspond to how *NIX does things- conclusion before the reason, basically.

Posted By: BC_Programming
Last Edit: 19 Oct 2019 @ 03:22 PM

EmailPermalinkComments (0)
 01 Apr 2016 @ 11:03 AM 

For quite some time now the idea of planned obsolescence has been somewhat commonplace. Computers in particular are often quickly considered out of date or “obsolete” only a few years after they have been used. Operating System versions that are older are met with a certain scorn from some people. I’m convinced, however, that there is a strong trend where the advantages of the latest and greatest hardware and software makes a dramatic falloff and furthermore that the speed with which a system actually becomes difficult or impossible to use for current-day tasks is falling dramatically.

for technology, it is a not uncommon mindset that it becomes useless very quickly, relative to other industries. And there is certainly some prior art for that; for example, an original IBM PC wouldn’t be able to do nearly the level of things that a PC 10 years newer would be able to do. However, I don’t think that applies quite as well to today and PCs from 10 years ago.

Consider the typical usage scenario. What everyday tasks, software, or other components does somebody use that they simply cannot use with Windows 7? Which ones require a system from the past few years to do so? Windows 8 and Windows 10 are fine; but can anybody itemize a list of what those business people had to give up by using Windows 7? I can’t even contrive anything.

whereas a system from 1984 was not very useful for the common tasks of a user in 1994, or required that the user tolerate it’s slowness, nowadays older systems can pretty much always be utilized for a modern task.

A prime example is the IBM Thinkpad T41 laptop I picked up for cheap off eBay. This laptop was released in 2003 and is 13 years old. The time difference is equivalent to using an original IBM PC in 1996. And yet here I am, writing a blog post on that system with absolutely no problems whatsoever, in a modern, up to date browser and a modern up-to-date Operating System (Linux Mint 17.3 XFCE).

This is why statements like the example I give seem so strange. It is as if the release of new OS versions suddenly make those older versions unable to perform the same tasks they did previously. We don’t see mind-bending amazing new features like VFAT in new Windows versions today, so the previous versions work just fine, and for the security conscious after it’s lifecycle expired, there is always Linux.

I wrote this Blog post on a Laptop that is 13 years old. old PCs are old- but they are no longer obsolete in the modern day, particularly as gains in CPU technologies have started to level off. I don’t need a Quad core with hyperthreading to write a text document.

Posted By: BC_Programming
Last Edit: 01 Apr 2016 @ 11:03 AM

EmailPermalinkComments Off on Perceived obsolescence
 21 Mar 2014 @ 11:01 PM 

One interesting trend I’ve noticed on tech-related blogs and articles is a strange focus on Linux- for example, “10 reasons to switch to Linux” or “Why I Switched to Linux”. These sorts of articles and posts are fine, but I’ve noticed a disturbing trend whereby the articles have such a strong bias that it practically dilutes the legitimate content of the article, and even removes any real value from it -turning it into nothing more than somebody typing 1000 words about nothing and based on nothing just to make a few bucks off the ad revenue.

Sort of like what I do here, except I don’t call myself a journalist.

Thing is, the problem with such articles on tech sites is they are coming from allegedly qualified individuals who should know what they are talking about, but they continue to repeat ridiculous fallacies about Operating Systems. There are a lot of real, actual benefits to using Linux but these posts and articles deluge you with idiotic reasons that in many cases aren’t even true.

The best way is to consider a specific example. Unfortunately I don’t want to give them the satisfaction of having ad revenue, so I’ll just take some central points that such articles almost always profess, and why I find them to be inaccurate.

“Windows always requires constant tweaks”

I Find this to be a curious argument, because in my experience, it has been the opposite. Even the most easy-to-use Linux OS will require a good level of scripting experience to use with the same level of customization as Windows; and you don’t get that functionality out of the base install in most cases. There is also the consideration of the script being compatible as well as upgrades. A specific case in my instance was that I wanted a wallpaper slideshow- sort of like Win7 has. The package manager of the distro I was using had about a dozen programs claiming this ability, but not a single one worked. Turned out I was using Gnome 3, and they were built with Gnome 2. I found one program (Drapes) which had a Gnome 3 plugin- that didn’t work as is, but I was able to find a freely distributed patch file for the plugin to fix it- that didn’t work either. After a few days if trying to get this basic capability in the Linux distribution I was running, I had about 2 dozen programs for switching wallpapers installed and had no idea which files they changed on installation- bash.rc had changes, and some of them installed background services. They had the common theme whereby they didn’t work, though.

I managed to piece a script together which I discussed here. I them realized my distro didn’t have sound notifications when I plugged or unplugged USB drives. I wrote another script to try to get that to work, but I either lost it or don’t have it. It was after this I realized that this held to me no real advantage over Windows; I could write a Windows Application to do all those same sorts of things if I needed too, but in fact the capabilities I was writing scripts for was built into the OS.

Therefore I find the argument that “Windows requires constant tweaks” to be a bit misleading. First off, almost any System is going to require software maintenance, and Linux is certainly no exception to this- you can’t just load up 30 different wallpaper change programs and have them fighting with your desktop manager by constantly interfering with one another. Additionally, I find that Linux requires more tweaks; this is it’s weakness but also it’s strength. The idea is that for such new capabilities and tweaks the person who creates it shares it with the world at large so other people seeking the same capabilities can simply use an existing solution. The problem is that this exact model works perfectly fine regardless of the Operating System anyway- and Other Operating Systems often have more solutions and tweaks of this nature- and often the tweaks and programs written for Linux are Desktop dependent or even package manager dependent.


“It’s Stress-free”

This is perhaps the most ill-informed sort of reasoning I’ve ever heard. It is far from stress free and to pretend that somehow a person switching from Windows will feel like they are prancing through an open flowery meadow of stress-free non-worry the moment they switch is anything but positive for the system being condoned. The only time Linux is “stress-free” would be after you have become very familiar with the system, but then you have just as many annoyances as you do when you are familiar with any system. It’s a sort of software infatuation, where you are so smitten with a system that you can see and possibly even elevate the positive attributes, while considerably downplaying real shortcomings the system may have.

“Linux is secure by design”

Every system ever designed has flaws, security problems, and exploits that can be used to get into those systems in the wild. Even FreeBSD, which has a meticulous security audit process, does not make you immune. As it currently stands the only reason Linux has any safety from maliciously-intentioned software is because there is no incentive to write malicious software that runs on Linux. If- as many people seem to want- Linux becomes a dominant Operating System, we will see serious exploits and malware being developed against and for that system and it will not be any different than the alleged “security nightmare” that Windows supposedly is.

“Fast And Gorgeous”

This is not a fallacy, though I find it to be rather irrelevant. It also depends on the distribution- if you want flash and pizazz you can get a distro suited for that taste; if you want something unassuming or simple, you can get that as well. One issue I find with much Linux software is that one thing that keeps getting done over and over again are desktop environments. It would be nice if there was more effort pooling being put into trying to make other environments better, rather than deciding to make a new one entirely.

There are a number of similar statements made in support of it, but one thing I find most disturbing is that a lot of the Linux appeal rides entirely on the waves of dissent for Windows; the people don’t really give a crap if the OS they are using is actually better than Windows- they just don’t want ot use Windows. That’s a fine reasoning on a personal basis but it’s a pretty damned crappy one at coming up with the actual Better System. At least FreeBSD and the other BSD communities don’t involve themselves in such idiotic slapfights, and instead focus on actually building good, usable software. It’s not perfect either- it can be tricky to install and there sometimes aren’t drivers or other software that you need, but the advantage is a lot more of the BSD is committed to making BSD better. They improve their systems over time, whereas a lot of Linux people just try to make Windows look worse.

Windows 8 has really sparked a movement in this regard- there are many people who, for whatever reason, have decided that somehow Windows 8 somehow goes beyond some imaginary line in their minds that Microsoft should not have dared cross. It is merely coincidence of course that this happens with every Windows Release ever– For example, 95’s release was the beginning of the end for Microsoft and people swore to never upgrade; Windows 98 was the beginning of the end for Microsoft, and people swore not to upgrade, Windows XP, Windows Vista, and even in many cases Windows 7. And now what we have pretty much the same thing. With Windows 95, people latched onto the Start menu and Windows 95’s evil way of organizing programs and it’s evil document-centric approach that was trying to do too much for the user, Users swore that they would never use Windows 95, that they would not stand this forced upgrade, and would stand firm with their copy of Windows 3.1. With Windows 98 people latched onto Active Desktop like bloodthirsty leeches, sucking it dry until they could no longer complain about it, and swore they would stick with Windows 95, which was obviously the last version made before some imagined downhill tumble… With Windows XP, people latched onto the default theme, saying it’s default theme’s colourfulness “fisher-price” was too playful for a serious OS, and they swore that they would stick with Windows 98- the last version of Windows released before Microsoft made the fatal mistake of abandoning the crappy ancient DOS-based codebase that was well-known for problems and instead decided to use their NT codebase which had already proven itself stable for the previous 8 years. “The fools” people said. “Why would they replace something that kinda sorta works most of the time with something that works all the time? And how will I run my 20 year old copy of Lotus 1-2-3? This is a forced upgrade!”, With Vista it was UAC. With Windows 7, it was how it hardly changed (more often people praised it for “fixing Vista” even though it practically changed none of the same problems people decried in Vista). With Windows 8, it is obviously the Modern UI that has been in the crosshairs of badly constructed arguments to ignorance. With each version, there were people who either swore to use the previous version, or swore off Windows and the evil Microsoft empire (The fact that people who had not really been a Microsoft Patron for years swearing off and boycotting Microsoft’s new products as if somehow that will hurt MS right then and there is a bit hilarious though).


IMO a lot of dissent with new systems- and this applies outside of Windows- to things such as Unity- is based simply on not being familiar with the new system. The interesting thing is that switching to Windows 8 from Windows 7 is going to be easier than switching to Linux, so I’m rather boggled at the logic, where Windows 8, by adding a new complementary user-interface model designed for providing a single development platform that can be used across various devices, has somehow ruined everything. People focus on Modern UI- usually referring to it as “Metro” because they have a case of recto-cranial inversion) and completely ignore pretty much every other aspect of the system- much of which is improved over previous versions, or entirely new.

Posted By: BC_Programming
Last Edit: 17 Oct 2014 @ 03:58 PM

EmailPermalinkComments Off on “They really did it this time!”
 24 Sep 2013 @ 5:53 PM 

Recently, Valve announced their upcoming ‘product’- a Free Operating System called SteamOS.

Steam OS is the culmination of a year or so of complete and utter cluelessness by Gabe Newell on Software products like Windows 8. Remember how he said that Windows 8 was a “catastrophe” and would be a “launch failure”? You might have expected him to change his tune when his very own Steam showed that 8% of Steam users were on Windows 8; whereas every non-Windows OS barely broke a single percentage point combined. He still stands by his ignorance. This ignorance included a completely misunderstanding of pretty much every single thing about Windows 8. His claims are that it is encouraging a closed gaming marketplace. It’s not. Desktop Applications still run. Desktop Applications still install; in fact you can even have installers to install Modern UI applications. Most games aren’t going to be using the WinRT APIs, though, so any and all argument about a “walled-garden” is entirely specious.

The problem is every “argument” against it starts with the postulation that you [i]want[/i] your games on the Windows Store. Why? That’s stupid. You can still use the same traditional digital distribution you do today. The Windows Store is only useful to you if you happen to have a WinRT Application that you would like to deploy to WinRT and Desktop platforms. Some simple games may fit this, but most games do not. And as a result, the argument about the Windows Store being closed is completely tangential. THhy argue that they need to actually have their Windows Store links point to another retailer. Well, my first question is why do they have a Windows Store link to begin with? Windows 7 doesn’t seem to suffer from the lack of a Windows Store and completely ignoring the fact that [i]the standard Desktop still exists in the Desktop versions of the OS[/i] I suspect is almost done entirely on purpose.

so, with the above out of the way, based on Gabe Newell’s various quotations on the subject, I can safely say that he has practically no understanding of Windows 8, the Windows Store, or any of those related technologies and his “concern” over it in regards to the gaming industry is based entirely on a castle of FUD he has built himself.

But to bring this circus act together, we have SteamOS. Apparently, SteamOS is Gabe’s answer to Windows 8; it’s more or less a crappy HTPC that runs some Valve Software and is based on Linux, and might be able to play almost 4% of Steam titles. Wow. Colour me impressed. I can totally get behind them working on this game company working on an [i]Operating System[/i] instead of actually starting any sort of development on the most anticipated game sequel ever. For somebody who throws their weight around in Gaming development circles they seem to be doing very little actual game development.

The fact that people are hailing Steam OS as some good thing that everybody in the gaming community needs makes me sick. Steam is still as awful a platform as it was ten years ago. The irony is that back then the complaints about a new closed gaming marketplace were directed at Steam. How can they throw those exact accusations at Microsoft when they very clearly are [i]running their own closed gaming marketplace[/i]? Steam decides if or if not a game get’s listed. That’s the very definition of a closed system.

With any luck Valve will either wisen up and get rid of the clearly incompetent Gabe Newell who has used his position almost either maliciously or stupidly for spreading idiotic FUD based on so little research the fact that he is still chiming the same old song and dance makes it difficult to consider him cognitively capable of being a circus clown, let alone running one of the biggest software distribution empires in existence today.

Posted By: BC_Programming
Last Edit: 24 Sep 2013 @ 05:53 PM

EmailPermalinkComments Off on SteamOS: “That’s a nice Iceberg, let’s crash into it”
Tags: , , ,
Categories: Games, Linux, Windows
 23 Nov 2010 @ 7:09 PM 

Alright, so, I had finally gotten sound to work. it was wonderful. Sure, things ran a bit slow.

And then poof, out of nowhere- Quite literally, I made NO code change whatsoever, the program is now crashing with an OutOfMemory error. From- where else? the god damned GDI-Plus/Cairo. Who the fuck wrote that thing? Every single problem I’ve had has been related to that Piece of shit. If you’re going to write a compatible library, do it properly.

Another tidbit: I love how everybody who uses Linux says “Linux is more stable” perhaps the OS is, but when it comes to Mono you may as well leave any stability, mental or otherwise, at the door.

“MonoDevelop, please show me the contents of this variable in the locals window”

“naw, I’ll crash instead”

“MonoDevelop, please show me the locals window”

“sorry my window has gone dark again.”


It’s DRIVING ME INSANE. I finally get the thing working and then out of nowhere (again, I made absolutely no change to the code) it decides, “hey, you know what, I’m broken again, just for shits and giggles”.

What makes even less sense is it only crashes in certain locations. It still draws the sidebar just fine. the background is drawn. and so forth. Why the hell does it refuse to properly draw some items? I finally, after struggling for far too long to get the bloody IDE to allow me to set a bloody breakpoint (you know, those things that worked perfectly fine in Turbo Pascal 25 years ago?) I threw in a few try catches because the error was not being handled in the right place (of course it would have been easier to discover this if I had been able to set breakpoints or had a clue where the Trace.WriteLine output was going), so I discover the problem was in cBall, when it tries to draw. Somehow drawing a god damned Solid Ellipse is just so taxing that it runs out of memory. Because that makes sense.

And then I made a few changes, and the error was now a NullReferenceException in DrawSideBar, so I thought, good! Maybe I’m finding out where the problem is.

So, silly me, I believed that MonoDevelop wasn’t being a huge steaming pile and tried to use the debugging features, you know, the ones that programmers might use, like say, placing a breakpoint in said routine in a crazy attempt to determine what was null.

OH! but that is not going to fly! I try to run the program in Debug, as one might, and the poor thing refuses to start! Mono Essentially crashes! Oh the JOY of this IDE, it simply screams “please, don’t use me the way you might expect, most of my features are written by illegitimate children of famous actors, and are therefore unusable except from a distance using bad glasses”.

So I try again, and this time mono really does crash. This is bordering on psychotic folks.

So, I’ve decided that if somebody wants a Linux version of, at least, this program they can either figure it out themselves or look elsewhere.

I tried to make a small java test version but I couldn’t figure out how to use swing. By which I mean I couldn’t import the library. But that’s another story.

EDIT: cleaned up my swearing here 😛 it was a lot even for me. Also, in the meantime I was able to create a small working application but couldn’t find the motivation to bother trying to figure out where swing paints. (having to look up in the documentation for exactly what routines to override, as opposed to being able simply type “override” in C# and see what I can override? No thanks. (also, I am probably clouded by my past attempts to work with java back in the “golden days” of the standard Java.AWT classes, which had the magical ability to provide sub-standard, barely OS-oriented controls for each Operating System.

Posted By: BC_Programming
Last Edit: 29 Nov 2010 @ 01:33 AM

EmailPermalinkComments Off on Mono nonsense
 22 Nov 2010 @ 4:55 PM 

No, Not the kissing disease, Infectious mononucleosis, the open-source .NET CLR interpreter and class library.

.NET; I might have ranted about this before, if not on my blog, elsewhere. most of my arguments were against it, being a VB6 using ignorant buffoon. In any case, I’ve found C# to be an awesome language. One of the obvious downsides is that for the most part programs written in C# using Windows forms cannot be run on other systems.

The concept of Mono is to change that; remember, C# isn’t a Microsoft standard, it’s an ECMA specification, and Microsoft holds no copyright over it or anything like that. Mono is a relatively huge undertaking; the creation of something on the scale of a Virtual machine as well as a class library is gargantuan, and of course there is very little hope for 100% success.

On the whole, Mono performs it’s primary goals admirably; there is a GTK# framework that can be used to develop windowed applications… of course then the installation on a windows PC would require the install of the Mono GTK# framework, but I digress. In any case, applications can be developed and the C# code interpreter (for on the fly syntax highlighting) as well as the compiler are top-notch and seem to work well.

My only beefs can of course be in the class library. Of course, re-implementing the class library provided by MS on non-windows systems is not something that can be done in a single afternoon; this stuff takes time. My attempts to create a Mono-compatible project have been stifled, however, by seemingly innocuous issues. AlLlow me to explain.

As many reader may be aware, I have been working on a “upgrade” of sorts to my now ancient “Poing” game, which can be found on my downloads page; the original game was written in Visual Basic 6, and, in it’s earlier incantations didn’t have a single Class; it was all based on User-Defined Types (structures for those privvy to C parlance) and functions; (short explanation: it was made before I understood classes). Later, after I had learned about classes, I refactored everything into classes. This is all rather redundant; in any case, I have since created a new project in C#, in an attempt to learn about GDI+ as well as what appeared to be a different (in some ways) painting model. As one can see by the youtube videos I have posted on it, development has gone well.

The idea occured to me, after Tux2 (of http://www.jrtechsupport.com/) managed to create a Mono-workable, if soundless, version of my earlier C# game, BCDodger that worked in Linux. Sound was unavailable as a result of my choice of sound library, the IRRKLANG library, while truly usable in Linux, doesn’t have a wrapper that works in Linux (or something, I don’t know… it uses DSound or something, I forget). In any case, I have since added the ability for various sound engines to be used, and have added working implementations for Open-Source and Linux-available Sound systems, such as NBass (as well as a broken fmod implementation, let’s ignore that though).

Much obliged, I had decided to try to get it working via Mono as well; this was facilitated by my recent reformatting of my laptop to run a dual boot Windows 7 and Mint 10 system. Installing MonoDevelop and all that, etc.

So, I of course open the project in Monodevelop, quite ready for errors relating to porting.

The version I am using is MonoDevelop (and I assume also Mono) version 2.4, for those following along.

My first hurdle was getting my Appdata files for the program in the right location; on windows systems they are placed in the application data folder; so too they would need to be on a Linux system. Thankfully, a quick C# program run on the Linux machine cured this issue:

Which gave me, on a Windows system:

Nothing particularly out of the ordinary there. So, running the program on a Linux machine:

which gave me what I needed: the appdata folder “BASeBlocks” needed to be copied to /home/bc_programming/.config.

Doing so was easy enough; the file manager on Mint 10 (dolphin) is different from windows explorer but hardly paradigm-breaking.

That copied, I simply threw the source folder as it was on the Visual Studio 2008 projects folder into the MonoDevelop projects folder (well, not really, it was /home/bc_programming/projects/ which I suppose means that any program that uses a projects folder will use it, oh well.)

psyched as I was I ripped into it with MonoDevelop, ready for anything! well, nearly anything.

My first error occured on line 107 of “Block.cs”:

Java programmers may be thinking “ew uppercase characters” to them I say be quiet you. Anyways, the problem here was that there was no “Sum()” Extension method defined. Which I found odd. Oh well, though, I simply created my own:

this solved the immediate issue of the “Sum()” extension method. (For more info on C# extension methods, see here)

My next hurdle was on line 540 of cBall.cs:

The error was something to the effect of not being able to pass a delegate or method group to a lambda expression.

oddly enough, the fix was the change the “q” to an x… and after it successfully built I was able to comment out the “new” line (with the x rather then a q) and uncomment the original. very odd.

In either case, now I was confronted with what I knew to be the biggest issue; the fact that I had to now discover how to set it up so that I was able to use the same nBASS library, but so that the nBASS library was “silently” made to use the BASS.so linux library, rather then bass.dll which wouldn’t load either way.

The first step in this process was in finding bass.so. Hoping for the best, I pulled up good ol’ synaptic package manager.

No luck there 🙁 so, I went into the depths of the internet….

the BASS for Linux (note the lack of the n prefix; it’s the core BASS library that the nBASS dll is wrapping) can be found here

this topic; or, the original post, to be precise, gives the download location for the Linux source files for BASS 2.4, which can be found at http://www.un4seen.com/stuff/bass24-linux.zip

So, I downloaded the zip file, extracted it to a folder, and am about to attempt to compile it. (there is a libbass.so that I could probably try, but I think I’ll compile it myself instead).

Before I continue, however, I would like to mention something that has most impressed me about Mint 10; the multiple desktops. Now, this is hardly a new feature; programs can be downloaded that do this on windows, and windows itself has built in API support for multiple desktops; however, what impresses me most is that when you activate a window on another screen, it switches to it; what I mean is, for example, in this instance my FF download window was on another desktop (no idea why) and when I went to open the downloads window via Tools->Downloads, it did the fancy compiz box animation (as I have selected in preferences) and switched to it. very cool. But enough if my gushing over the unexpected presense of sanity in the UI design of a Linux desktop environment! back to my attempts to get BaseBlock working on Linux.

my attempts to make the bass project, however, failed:

Oh the humanity! now I had to learn about this package nonsense. I first suspected perhaps, as evidence by the fact that it wasn’t found, said package wasn’t installed; so I did a quick sudo apt-get install libglade-2.0 … it reported it was installed already.

after a bit of effort, and installing a few dev packages, I gave up. I was able to resolve the missing dependencies but then it complained about a missing .h file (which was indeed missing and clearly should have been present) so I gave up on that, and am at the time currently trying to simply use the .so file included. An additionally problem that arises here is the obvious fact that I am using a x64 Linux system, working with C# code written on a x64 windows system but targeted towards a x86 system, problem being that to my understanding Linux is not as lenient when it comes to architecture differences; but I suppose I’ll figure that out for myself if it’s the case.

In any case, I am now attempting to get the nBASS library to wrapp around libbass.so rather then bass.dll; from my research if the imports are the same I should have no problem creating a dllmap entry in the appropriate config file. From the documentation it would seem that discovering where that config file goes is left as an exercise for the reader.


pasted libbass.so in the “Debug” folder (alongside the dll).

Copied the BASeBlock.config file from the project root to the debug folder; renamed to Bass.Net.config.

opened preceding file in gedit; it now looks like this:

And now, I attempt to run BASeBlock… recall that it now compiles on Linux, so it’s just a matter of making it work. I could, in a worst case scenario, construct a “nullsound” driver that simply stubs out the sound playing interfaces. But that seems like a bit of a cop-out. IN any case, attempts to run it resulted in the same error; clearly either the documentation I was reading was incorrect or I was not interpreting it properly.

I did a few more googles and came upon this page, which, despite being about something completely different addressed the same problem; that is, translating the dllimport(whatever.dll) into imports of functions from Linux .so libraries. namely, it told me where the Mono parameter file was- /etc/mono/config. I quickly opened the feller using gedit:

I tossed in the line:

and crossed my fingers…

It still didn’t work. I guessed maybe mono only loaded that stuff up when it was started? So I restarted monodevelop.

excellent! a little progress. Now I was still getting the error, but it was complaining about libbass.so missing. At least we’re getting somewhere.

It still should have found the file; however, I decided that instead of just throwing it in the app directory (because god knows where Mono is truly looking for it; even putting ./libbass.so in the dllmap failed, so Mono clearly thinks something else is the “current” directory. Instead, I decided to simply cp it somewhere globally accessible;

It still didn’t work.

Anyway, I messed around with the config file and the dllmap attribute and no matter what I put it it refused to find the file; clearly I’m missing something obvious (maybe capitalization? a missing slash? who knows). In either case I decided to defer that work to later on; I’m sure there was more to be fixed afterwards.

So, I created the aforementioned “Null Sound” driver; it worked fine. compiled alright. Encountered a bunch of issues during startup relating to my use of the \ as a path separator, whereas Linux uses /, fixed this with a simple Replace to change all slashes to the slashes of the OS (Environment.PathSeparatorChar).

It still refuses to start; Some gdi plus error. I have no idea how to workaround this, since it seems to be related to the windows forms, and has nothing to do with my own code, but rather with some configuration option. I recall Tux2 working around a similar error in BCDodger but I wasn’t paying very close attention and forget what the fix was, or even if he mentioned it. Either way, at least now BASeBlock compiles on a linux system, and most of the code-related oversights have been resolved.


I’ve managed to solve both issues; not at once of course.

First, the loading issue was fixed; pretty troublesome. In my attempts to resolve the problem I created a number of projects that used the same Image.FromFile() method to load pictures, and they worked fine.

Clearly, the problem then was not in what was not visible; the difference between the two. I realized that the difference was pretty clear: in my test projects, I was loading the images from within the form’s Load event; in BASeBlock, they were being loaded in a static constructor. So I decided to try to load the images elsewhere; I converted the static constructor to a static function, and called that function in the form load; there were a few other changes that I needed to make, mostly in the form of initializers attempting to use values that wouldn’t have been initialized.

The game started and ran fine with the NullSound driver.

Now, to fix the Sound; I opted to try to get nBASS working.

the solution was actually quite simple; merely a dllmap for bass.dll to libbass.so, and placing the x64 libbass.so in usr/lib was enough, and sound worked fine.

Unfortunately, it’s still slow as hell but at least I think that’s Mono’s fault.

Posted By: BC_Programming
Last Edit: 20 Jun 2013 @ 12:32 AM

EmailPermalinkComments Off on Porting BASeBlock To Linux, and thoughts on Mono
Tags: , , ,
Categories: .NET, API, C#, Games, Linux, Programming, Windows

 Last 50 Posts
Change Theme...
  • Users » 47469
  • Posts/Pages » 397
  • Comments » 105


    No Child Pages.

Windows optimization tips

    No Child Pages.

Soft. Picks

    No Child Pages.

VS Fixes

    No Child Pages.

PC Build 1: “FASTLORD”

    No Child Pages.