My Blog

When I migrated my website to Jekyll a few months ago, I used a free template for my layout. Although it looked quite good, it came with a major tradeoff. It used Skel, a JavaScript framework for responsive websites. Skel loads arbitrary CSS stylesheets with JavaScript, based on the user’s screen resolution. This may sound convenient, but the page will load visibly slower, because the stylesheets will only load after all the JavaScript is loaded and executed. See an example of Skel in action in the following listing:

 1skel.init({
 2    reset: 'full',
 3    breakpoints: {
 4        global:   { range: '*', href: '/css/style.css', containers: 1400, grid: { gutters: 50 } },
 5        wide:     { range: '-1680', href: '/css/style-wide.css', containers: 1200, grid: { gutters: 40 } },
 6        normal:   { range: '-1280', href: '/css/style-normal.css', containers: 960, viewport: { scalable: false } },
 7        narrow:   { range: '-980', href: '/css/style-narrow.css', containers: '95%', grid: { gutters: 30 } },
 8        narrower: { range: '-840', href: '/css/style-narrower.css', grid: { collapse: 1 } },
 9        mobile:   { range: '-736', href: '/css/style-mobile.css', containers: '100%', grid: { gutters: 15, collapse: 2 } }
10    },
11    // ...
12});

Since the launch of Let’s Encrypt CA in late 2015, obtaining TLS certificates has become cheap, quick and easy. Statistics this month showed Let’s Encrypt has yet issued nearly 1.8 million certificates. But it seems like this information hasn’t arrived at some website owners and API developers.

So I wrote a little script to poison DNS requests and let a little node.js script exchange all pictures requested by the victim (I will perhaps blog about this script another time). Sites and apps using TLS are perfectly fine, because they will reject connections to the fake web server without a valid certificate. Without transport security, things get mad.

As a mainly WPF developer, I decided to take a look at the new Universal Windows Platform (UWP). In this post, I will focus on some small differences between WPF and UWP, including StringFormat and DataTemplates.

Adobe just released some new security-related patches for their Flash Player. My question here is not “why again”, because I expected that. We all expected that. The real question is - who the hell still uses flash? And why are guides like “This is how you secure your flash installation now” so popular? (The expression “security hole” is always particularly funny; that’s obviously no hole here, because a hole clearly has an edge ;) )

When loading unmanaged / native libraries from managed .NET code, the normal way is to use the “Platform Invoke (P/Invoke)” mechanism.

1[DllImport("shell32.dll", CallingConvention = CallingConvention.Winapi)]
2static extern int DllGetVersion(ref DLLVERSIONINFO pdvi);

The problem

P/Invoke has an annoying limitation: You can not load an x86 (32bit) library into a 64bit process and vice versa. This is especially problematic when your application is compiled with the “AnyCPU”-flag - which lets the .NET runtime decide which architecture to use at runtime - and there is only one 32bit version of a specific DLL. If recompiling the library against a different architecture is not an option, you have to find another solution.