Rotten Apples: how BootCamp can deprive of dignity

I have a somewhat old (for the Apple standards) MacBook6,1 from late 2009. It surprisingly supports the newest macOS Sierra, as well as DDR3 (thanks to the otherwise terrible NVidia north bridge), while being a Core 2 Duo machine. It also supports BootCamp, initially designed for Vista. I obviously love Vista, as it’s the wrongest version of Windows since Millennium, surpassing even the ridiculously unfinished Windows 8.x. Since Vista does not work anymore with the software I need, like Chrome and Visual Studio or “need”, like HexChat, I’d have to settle for something newer. Windows 8.x is the next wrong thing, but it creates a set of really sad, stupid and downright outrageous problems. Each of them has a solution that solves one issue, while creating an array of others, all equally unforgivable. Here’s a story of a MacBook and Windows 8.1.

The laptop is indeed old, and the last version of BootCamp it supports is 4, designed for Windows Vista and compatible with Windows 7. But Windows 7 does not support BitLocker, and I need to keep both my SSDs encrypted. So the lowest version of Windows I can pick is Windows 8.1 Pro. I wanted to perform the installation as quickly as possible, so first I decided to download all the updates using AutoPatcher and slipstream them with NTLite, with the drivers supplied by the BootCamp installer. I also removed all the Metro apps, because everyone knows thay’re useless. NTLite was working during the night, fighting with 200 updates and 40 drivers and the next day I had a working installation source for Windows 8.1 Pro.

Before ramming the pendrive into my MacBook, I decided to check the installation on a VM first. The result was not satisfactory. The account creation process was indeed faster without Metro crapware, but there were other problems. First of all, there were updates not downloaded by AutoPatcher. Some of them were about .NET, so they could be explicitly requested, but few others were only accessible via the Windows Update Catalog. I downloaded them manually and added them to my slipstream stash. Finally, there were two updates that turned out not to integrate successfully. One of them was the giant “Windows 8.1 Update” update that was around 800MB heavy. It turned out that the failure of slipstreaming this one was a good thing. Why? Well, because the Metro apps stopped working.

Now, you shouldn’t remove all the Metro apps, because some of them are vital components of the OS, like the Immersive Control Panel, or some networking gizmos, like Teredo. That’s why only the per-user crap without the shared libraries ought to go. I kept all the system stuff and two Metro apps: Store and Immersive Control Panel. Unfortunately, DISMing out the apps from the updated image breaks the entire TwinUI stack.

First I thought “who cares?” but quickly afterwards it turned out that the Immersive Contol Panel actually serves some purpose. I can live without the Store, whatever, but the following things are impossible without the PC Settings app:

  • ability to create and validate the Microsoft Account
  • ability to start OneDrive (?!?)
  • sending or receiving files, or even pairing the device, with goddamn Bluetooth!

Those were the things I need. Magically, the TwinUI subsystem was fixed by re-applying the Big Patch using ordinary Windows Update. An ugly workaround, but that was enough to have a working ISO for MacBook. I slipstreamed the remaining updates with NTLite during another night and got an installation pendrive. Naturally, giving up on removing the Metro apps was not an option. It required an annoying trial-and error, but finally I got to the stage where all the “provisioned” AppX packages were gone. What are the apps that you need to keep? Well, I am now richer with this extremely worthless knowledge thanks to the expansion of Windows 10, but the apps you need to keep in order not the break the TwinUI stack and, in consequence, the entire image are: Immersive Control Panel, Store, PlayReady, everything related to the Camera support (even the MoCamera app – you can’t remove other Camera components because they’re updated by Windows Update, not Windows Store and removing only the MoCamera applet doesn’t really remove it, only breaks it, providing a dead tile), some Teredo crap and FileManager, which turns out to be OneDrive and Photos viewer. Everything else can be thrown away. The new user accounts will be created much faster and the system performance won’t be periodically crippled by the Store updates.

Now the image was 900MB thinner (900MB of worthless apps! how!?) and workedcorrectly in the VM, so time for actual hardware has finally come. I booted the MacBook with the Alt pressed to get the boot device picker and surprisingly, I got Windows Setup and… EFI Boot! I was really happy about that. I immediately selected the modern EFI boot, the installation went reasonably fast, rebooted and… nothing. picking the Windows local EFI Boot did nothing, not even a bluescreen. Once again: why?

The answer is sad. The Windows 8.1 Setup did found a macOS EFI System Reserved partion, placed itself in it correctly but was apparently too surprised that it’s being installed on a different drive that the one with an EFI definition partition. Apparently, this simple scenario is something not supported by the Windows 8.1 Setup. The only thing I could do was to restart the setup process using the MBR boot, and lose all the EFI little advantages like a non-retarded screen resolution. This time it worked. But it only logged me in.. once. After installing the crucial Big Update and a mandatory restart, the screen went blank just after the preboot sequence. There was no obvious answer about why it is happening and I started frantically searching for an answer, which was extremely embarrasing. The reason of the blank screen is the inability to initialize the graphics adapter correctly. The system won’t default to the VGA resolution, because the driver fits the hardware. It just doesn’t work. The drivers that borked the display were naturally slipstreamed from the BootCamp package. So I created yet another DISM, this time without the NVidia driver (what was I thinking…), allowing a yet another installation to fail in the same way. Why? Because it took the NVidia drivers from Windows Update, and those were broken as well. The last resort was to find out the last driver created for the GeForce 9400M chip. It’s the 341.95 release from March 2016. After that, support for the 9M series was dropped. I slipstreamed the giant bloatware driver package from NVidia and started the installation one more time. Passed the Windows Update, rebooted – and it worked! Finally!

Unfortunately, BootCamp is a piece of crap. All the drivers from the package were correctly slipstreamed, but the BootCamp core is not a driver. So it can’t be slipstreamed and has to be installed manually. Unfortunately, it’s mandatory for the following things:

  • brightness control (the built-in Windows 8 support doesn’t work, because the driver is ridiculously terrible)
  • Keyboard F* buttons (also should be supported by the driver, but aren’t)
  • clock settings (also should be supported by a driver)
  • trackpad (the trackpad drivers do not install correctly, also all the settings should be provided by it, not by the BootCamp dialog window)

So, the entire BootCamp is worthless. But it had to be installed, because the trackpad drivers do not install correctly, despite being slipstreamed. You can try picking them manually. It’s a fun thing to do. Either you break the trackpad AND keyboard support (in that case another reinstall awaits you! connecting external keyboard requires logging in, good luck with that then) or you actually pick the correct one from the randomly-populated list of identically-named drivers. But even then, you won’t be able to turn on the right click support. Because the trackpad drivers do not extend the Mouse control panel applet like virtually every other pointing device driver ever, but instead rely on the ticks in the BootCamp control applet. So the BootCamp suite had to be installed anyway. I robbed it from all the drivers, because they were slipstreamed already, and inly started the installer for the small BC support. Then, another red flags started showing up.

BootCamp 4 installer informed me that it’s not working with Windows 8 due to the compatibility issues. I obviously ignored that alert and turned on the option to impersonate Windows 7 and it installed correctly. I got my brightness control. I got my right-click. Now the final reboot and everything will be ready. I rebooted and the first window after logon was another alert of incompatibility of BootCamp. It has a tick “do not display it again” which I fortunately did not click and a cute little “Run anyway”. I hit it and… bluescreen. BAD_POOL_HEADER. Reboot. Again. Another, identical bluescreen. So right now, the only thing that prevents you from constant crashing is that little window that halts the BootCamp execution to inform you that it’s not compatible. And it’s right. BootCamp 4 simply does not work with Windows 8.1. I was really disappointed. To make everything worse, the Get Windows 10 icon appeared behind the incompatibility alert.

I had a moment of clarity: why not to try? I started the Windows 10 upgrade procedure, it took about 40 minutes and afterwards… no imcompatibility alert, BootCamp start right after logon and everything works! I started installing all the software, disabled the TPM requirement and switched it to the password prompt to start encrypting the driver with BitLocker. All the crap like Office 2016, Visual Studio 2015 and every other piece of software I need, seems to work. Windows 10 turned out to be the lowest acceptable verion of Windows on a 2009 Core 2 Duo MacBook.

The next challenge? After mounting two SSD drives, I want to extend the amount of RAM to 8GB, instead of 4. Everymac says that 8GB is supported by this device, but inserting the 1333 MHz 4GB DDR3 sticks results in the constant beeping at boot. Maybe the 1080 sticks will work…? Anyway, when I find a way to put 8GB into this machine, I’ll end up with the ultimate MacBook, the last one before discontinuing the line. All this in a classic white policarbonate, which I consider much prettier than all the following MacBooks, made of aluminum.

But the new 12-inch MacBook looks nice…

Is Windows 10 ready yet?

current status (March 2016):


Despite the (rushed) release that took place many months ago, Windows 10 still feels gravely unfinished, compared to the Insider program hype and, more practically, the robustness of Windows 7. Using the beta-level, unpolished and downright unfinished software is a popular argument against Linux. It can be easily said that unfinished software is wrong – that’s why it fits perfectly here. Let’s try and assess how much of a wrong technology Windows 10 still is, by compiling a list of things that should be done with 10 in order not to be a shameful disgrace and an unholy mess. The following list has a form of a “checklist”. If all the criteria are met, Windows 10 could be marked as a “Ready product” that passed any kind of QA. All the bullet points are either obvious or were explicitly announced.

Comments encouraged! We will continue to add significant missing parts of Windows 10, so feedback would be nice. If a features gets implemented, it will get crossed out of this list, but not removed.

  • New Settings App
    • does not collide with the settings from the classic Control Panel
    • is reasonably interchangeable between Control Panel
    • allows extensibility
    • actually works with UAC enabled
      • does not make sharing options disappear with UAC enabled
      • does not have the “this option requires lower UAC level” placeholder
    • deprecates the Control Panel entirely (as announced)
    • deprecates “Optional Features”
  • Edge Web Browser
    • PPAPI Extensibility
    • Windows Authentication
    • Web Notifications
  • Messaging and Skype
    • actually working webcam
    • file transfers
    • Lync bridge
    • deprecates the classic Skype client
    • removes the “get Skype” link
  • TwinUI Modern Apps
    • inter-app drag and drop
    • ability to disable touch
  • Alarms
    • ability to actually wake a computer to ring the alarm (Task Scheduler can do it)
  • Multimedia Apps
    • advanced Media Library
    • automatic playlists
    • Windows Explorer “Play to” feature
    • deprecates Windows Media Player by gaining similar feature set
  • Action Center
    • Shows more information on toasts
    • does not make Bluetooth requests disappear
    • integrates the Bluetooth icon
  • OneDrive placeholders
  • Office Remote that works with Office 2016 (it works on Android!)

Self-mutilation with .NET: Visual Basic on Linux

The worst way of using .NET on Windows is using C++/CLI. It connects the worst of both worlds: terrible archaisms of Win32 and somehow out-of-place bindings to .NET. But using C++ undoubtedly requires some actual skills and/or practice and quite often results in some actually acceptable code. This is not something we’re looking for here. So we need to find other candidates for the most annoying .NET activity. There are some strong candidates:

  • using F# (the language is sick, but it still requires some skills)
  • targeting an ancient version of the framework (like 1.1, which can’t be installed without warning above Windows 2003)
  • targeting an unreleased version of .NET 1.2/2.0 from Windows Longhorn (that’s more like it, but it might be a little too much)
  • using Visual Basic

The last option seems to be in a perfect balance between a really backwards and painful technology and a solution that actually makes sense. Visual Basic does work: it is functionally parallel with C# and still be can used as a code basis for all .NET applications, ranging from WPF to ASP.NET MVC (though strongly discouraged). It is often said that the bad opinion that VB.NET has is unjustified and outdated, because it originates in criticisms of Visual Basic 6.0 (“VB.COM”) and the disadvantages of VB6 are missing in VB.NET, but nobody cared to check it out. VB.NET, despite being marked as a direct successor of VB6 (versioned 7.0) is a drastically different language, fully object-oriented and much more powerful. Yet it doesn’t make it less strange: it’s not similar to anything else out there, it has its own ways of doing many things and requires a significant change in the way of thinking, especially from the people that previously used C#, Java or any other language with the slightest spark of sanity (Module1.bas, anybody?). Some people even look on VB.NET with disgust, and many others say that switching to VB.NET hurts their brain. Well, unless Visual Basic was your first programming language. Then, no matter what, you just love it. This is my case – I’m using Visual Basic since 2002.

That’s why we need to make it worse – since Visual Basic seems to work correctly, we need to pick some clinically retarded use case for it. Recent release of DotNet CoreCLR on github gave me an idea: let’s use Mono on Linux! Now, the .NET stack opened by Microsoft has not been integrated into Mono (yet), so even using the newest version of it gives us the in-house VB.NET compiler, instead of some fresh one. Moreover, the Mono stack is, despite some opinions, not the popular piece of Linux software, so it’s often neglected and kept in some ancient versions. This is the case in Fedora: it currently offers 2.10, which lags behind upstream very much – few years, to be fair. Xamarin releases half-official packages for Fedora with the latest 4.0.1 release, so I picked and installed it, only to discover that the VB.NET compiler in both 2.x and 4.0 is the same and nobody worked on it for the last 5+ years. This is gonna be great.

Visual Basic.Net Compiler version (Mono 4.0.1 – tarball)
Copyright (C) 2004-2010 Rolf Bjarne Kvinge. All rights reserved.

First, we need to create some “Hello World” to find out if Visual Basic support in Mono even works at all. It would seem that the logical way to do this is to use the Mono equivalent of Visual Studio: MonoDevelop. But this is not true. Bugzilla suggests that for the latest few years, the Visual Basic support in MonoDevelop is broken, even though it is shown in the Project type selector. It’s said to be related with the lack of support for targeting 4.5 for VB.NET. It’s actually much worse than that – manual fixing of the targeted framework does load the project, but it never produces any binaries. Not to mention that the apparent support for VB.NET ends on 2.0. That means no LINQ, no async and no parallel extensions. Since the IDE turned out to be useless, we need to go oldschool and use an ordinary text editor with syntax highlighting. I picked my favourite Geany. Initially, it didn’t colorize my code, because it doesn’t understand the “.vb” extension. Fortunately, it does support the VB syntax, so quick fiddling with the settings enabled the syntax coloring for the Visual Basic code. All set, so let’s write a simple program:

Module Hello
Sub Main()
End Sub
End Module

That’s it. Let’s compile it with the vbnc command. It compiles successfully and run with mono displays the aforementioned hello prompt.

Now, the single biggest mistake one can make now, is to assume that since Hello World compiled, the VB.NET is working. This is barely true. It’s a common mistake, present in many tutorials: this big jump from basic code into the more complex problems. So instead of believing that vbnc is not terrbile, let’s try and build something bigger. The most useless and needlessly complicated Visual Basic code I’ve ever created is the burnout flame temperature calculator I was forced to write at the university. I hate it so much, it’s the best candidate for that. It compiles without errors (naturally) or warnings on Visual Studio 2010 and up. I wonder how will the vbnc version 0.0.0 deal with the code? Not well, and that’s a really bad sign, the program is really simple:

Could not find the error message corresponding with the error code: 42021
/home/kamilek/Dokumenty/tp-is-2.4/Magic2.bas (3,20) : warning VBNC42021: 42021
/home/kamilek/Dokumenty/tp-is-2.4/Magic.bas (28,15) : warning VBNC42020: Variable declaration without an ‘As’ clause; Object type assumed.
/home/kamilek/Dokumenty/tp-is-2.4/ModuleCalcSolid.bas (12,17) : warning VBNC42020: Variable declaration without an ‘As’ clause; Object type assumed.
/home/kamilek/Dokumenty/tp-is-2.4/ModuleCalcSolid.bas (13,16) : warning VBNC42020: Variable declaration without an ‘As’ clause; Object type assumed.
/home/kamilek/Dokumenty/tp-is-2.4/ModuleHeat.bas (5,30) : warning VBNC42020: Variable declaration without an ‘As’ clause; Object type assumed.
/home/kamilek/Dokumenty/tp-is-2.4/ModuleRequiredAir.bas (15,15) : warning VBNC42020: Variable declaration without an ‘As’ clause; Object type assumed.
/home/kamilek/Dokumenty/tp-is-2.4/ClassAnswer.bas (24,23) : error VBNC30451: ‘vv’ is not declared. It may be inaccessible due to its protection level.
/home/kamilek/Dokumenty/tp-is-2.4/ClassAnswer.bas (28,23) : error VBNC30451: ‘vv’ is not declared. It may be inaccessible due to its protection level.
/home/kamilek/Dokumenty/tp-is-2.4/Magic2.bas (14,23) : error VBNC30451: ‘xs’ is not declared. It may be inaccessible due to its protection level.
/home/kamilek/Dokumenty/tp-is-2.4/Magic2.bas (18,23) : error VBNC30451: ‘xs’ is not declared. It may be inaccessible due to its protection level.
There were 4 errors and 6 warnings.
Compilation took 00:00:00.6190650

There are no error messages implemented! Is this some kind of a joke? All right, let’s start with the error messages. There are all the same error: accessing a non-existent variable. Moreover, they all turn out to be located in the same piece of code: a “For each” loop. Mono (or rather vbnc apparently doesn’t support the default types for the iterators in the For each sequence. It should. There is absolutely no problem with it using the official .NET Framework compiler. It’s an easy fix, just assign a type to the iterator. You can do it correctly: The String type for Keys and the Double type for Values, as it’s a Dictionary of String, Double. But you can also do it the retarded way, by declaring the iterator as Object. It actually works! This is because the real Mono stack is implemented correctly and indeed does not care about the type of an iterator in For each. It’s the problem solely with that dreaded vbnc. So, let’s fix everything the retarded way. Now the warnings.

The warnings in fact make more sense than the errors. They basically boil down to the same thing: default typing. There is no type set for two Doubles (the division of two other Doubles), so the compiler assumes the type on its own. And it does that terribly by taking the type of “Object”. Somehow the program works, it’s magically enough to assign any type for it to work, as long as it’s big enough to contain Double. Object does that quite right. We’ve made the program work and it’s not Hello World. But, let’s not fall for the same trap: flame heat calculators are not where .NET is used, they’re meaningless. Let’s try some business stuff. Like threads! Here: “How to: Write a Simple Parallel.For Loop” by Microsoft.Now let the fail begin.

Compilation ends with 62 errors and this is the code straight from MSDN. More precisely, this is what happens: That does not mean anything good. It, in fact, means that nothing works. It goes only worse after that. There is no way to run anything remotely complex or modern (above 2.0) in current Mono. The project doesn’t even say much about the future: Visual Basic support in Mono but there is a work item about taking from the open .NET imlementation from Microsoft on GitHub. Months passed and there is no sight of any progress. I know that nobody actually uses Visual Basic, but there still are some crazy people that actually do. Also, no matter what happens, VB.NET will always be my lanuage of first choice, becuase it was my first language and I just like it.

Anyway, the Visual Basic via Mono on Linux easily wins the contest for the worst way of using .NET ever.


Next time: web services with COBOL!