ModSecurity: Multipart parsing error: Multipart: Final boundary missing.

Turning off “added security” in the Dreamhost Panel helped a little bit, but I’m still occasional errors.

With SSD drives, this is going to become more and more of a problem until their capacity gets ramped up. We must manually select what we want on the drive to be fast, and put the other stuff on a cheap, large-capacity, mechanical drive. However, Windows and Windows applications make this very difficult.

For the purposes of this example, I will use Steam. Steam places games in “C:\Program Files (x86)\Steam\steamapps\common\”. Games can be pretty large. So when you get to the limit, you have to delete one of the installed games. For me, this is around 4 or 5 modern games, so it’s not very convenient. There’s a longstanding request on the Steam forums to address this functionality, because you can only install games to the drive Steam is on… or can you?

Windows Vista introduced symbolic links. They’re a feature that other operating systems have had for years. Prior versions of Windows could make “junction points”, and you can find that application if you’re using XP or lower, but for the purposes of this post we will talk about this new feature since junctions can cause unforeseen issues – particularly with system files.

LONG EXPLANATION

A symbolic link allows you to map a directory or file in one place to another without any applications understanding that it isn’t in the place they think it is.

So let’s say I want to put Borderlands – a 12 GB game – on another drive because I won’t be needing fast loading times since I already beat it. I would move “C:\Program Files (x86)\Steam\steamapps\common\borderlands” to “D:\steam\borderlands”. Now, Steam cannot find it.

The next step is to open an Administrator command prompt (type cmd into the Start Menu search, right click on command prompt, and go to “Run as Administrator”).

mklink /D "C:\Program Files\ (x86)\Steam\steamapps\common\borderlands" "D:\steam\borderlands"

Now Steam will be able to find it! If new DLC comes out and you’ll be playing more often, delete the symbolic link (the folder in steamapps) and move the folder back where it came from.

At some point I might make an app to automate this. Enjoy!

TL;DR

1. Move the folder elsewhere.
2. mklink /D [FOLDER] [ACTUAL FOLDER]

Link to gallery.

ApplicationsMenu is my first Cairo-Dock applet.  It is written in C# and requires Mono, NDesk.DBus, and libgnome-menus.

Its goal is to emulate the Mac OSX applications menu as much as possible with the API provided.

You can download it here: ApplicationsMenu Cairo-Dock Applet v0.0.1

The source contains multiple useful components:
1. A (beautiful) C# wrapper for the Cairo-Dock DBus API.
2. A wrapper for libgnome-menus
3. Modification of some C# Diff code I found online.

You can download the source here: ApplicationsMenu Source v0.0.1

Hopefully this is useful to someone else, as either an applet or example code.

I could go on a tirade about this, but instead I will just arm you with the knowledge you need to solve this problem and do what they don’t want you to.  The basic steps are:

1. Set up a HTTP proxy that rewrites the User-Agent string
2. Configure Playstation 3 network settings to use this proxy
3. Watch Hulu on PS3.

Naturally, I chose to expand my file server/router machine’s job by installing Squid 3.0 (proxy software), though you can set up any HTTP proxy on any machine on your network so long as it is capable of rewriting the User-Agent header.

Be warned, though, if you use Squid that there is a lot of conflicting information out there since they changed the configuration directives across versions. In Squid 3.0, merely add this to your squid.conf:

request_header_access User-Agent deny all
header_replace User-Agent Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; YPC 3.0.1; .NET CLR 1.1.4322; .NET CLR)

That User-Agent string is for IE7.  You may wish to change that to another common browser, or add a “Fuck you, dickheads” to it, but as long as it doesn’t say “PLAYSTATION 3″ then you should be fine.

DNAT            net             loc:192.168.0.2 all

The confusion stems from the fact that most consumer-grade hardware routers consider the DMZ to be “the place where I forward everything.”  Drove me nuts trying to figure this out, so hopefully this will help you.
Of course, to guarantee that your computer has that IP address when using DHCP, you must add to /etc/dhcp.conf the following:

host hostname {
    hardware ethernet [MAC address] ;
    fixed-address 192.168.0.2;
}

Disclaimer: All I know about Shorewall and networking are enough to get me by.

My file server/router is almost complete!

Here is my configuration:

• Mandriva Linux x86-64
• Gnome desktop
• Two similar nVidia cards with two DVI ports on each: 4 total DVI ports
• Two LCD panels of similar dimensions and a LCD TV: 3 total displays

Here is what I wanted to achieve:

1. All displays working at same time, but not necessarily as one large display (no Xinerama necessary)
2. Compiz graphics (no Xinerama)
3. gnome-panel spanning one display

Now, from a clean install of Mandriva, all I need to do is run nvidia-settings, turn on TwinView for my two matching panels, and everything is perfect… except for the TV.  If I attempt to enable the TV as a separate X screen, point #3 fails.  It doesn’t make any damn sense, but that’s what happens.  Applications sometimes still maximize to separate monitors (and sometimes don’t depending on my configuration – a lot of this is black magic to me).

It turns out that libgdk determines how things maximize and such.  Each display has a number of screens, and each screen has a number of monitors.  The maximization/panel logic apparently goes off of the monitors.

So what I did is I downloaded the gtk+ source RPM, dug around, and found the init_multihead function.  With a little fooling around, I now have hacked the code to look like this:

if(screen_x11->screen_num == 0)
{
screen_x11->n_monitors = 2;
int nWidth = WidthOfScreen(screen_x11->xscreen) / 2;
screen_x11->monitors = g_new0(GdkX11Monitor, 2);
init_monitor_geometry (&screen_x11->monitors[0], 0, 0,
nWidth,
HeightOfScreen (screen_x11->xscreen));
init_monitor_geometry (&screen_x11->monitors[1], nWidth, 0,
nWidth,
HeightOfScreen (screen_x11->xscreen));
}
else
{
/* No multihead support of any kind for this screen */
screen_x11->n_monitors = 1;
screen_x11->monitors = g_new0 (GdkX11Monitor, 1);

init_monitor_geometry (screen_x11->monitors, 0, 0,
WidthOfScreen (screen_x11->xscreen),
HeightOfScreen (screen_x11->xscreen));
}

That’s pretty much it. Keep in mind that you need a few dependencies to build GTK, so install the corresponding -devel RPMs.  If you’re not using an RPM-based distro, you probably know how to patch stuff already.  I didn’t bother building a new RPM, I simply ran ./configure –prefix=/usr and then make, and replaced the original one after making a backup.

A three-monitor TwinView setup will work fine (for GTK apps, at least).  To run stuff on the other display, use gnome-terminal –display=:0.1 or run export DISPLAY=:0.1 before running your app.  Now I can watch TV without restarting X, hooray!

By default, Compact Framework Pocket PC Application Projects (.exe) compile in a hi-resolution resource that either enables or disables proper scaling.  I haven’t figured that piece out, and I don’t really care because I had to make my application hi-res aware anyway when I was trying to figure this piece out.

Now, this is fine and dandy and transparent until you want to compile in important resources such as, oh, the File Version that you would see on the Version tab in the file’s properties (Right Click -> Properties).

For most CF applications, this is not a problem.  The AssemblyVersion attribute will still be placed inside the binary and usable once you load the binary.  However, let us not forget that the Compact Framework doesn’t allow us to unload a binary (and the Desktop Framework barely allows that).

So what is a Pocket PC / SmartPhone developer supposed to do?  We want to check the binary’s version, but we can’t!

Some have found solutions.  But they either involve 1. compiling in new resources manually or 2. changing your PlatformFamilyName to WindowsCE.  This can be done within the project manually by opening your project and replacing:

<PlatformFamilyName>PocketPC</PlatformName>

With:

<PlatformFamilyName>WindowsCE</PlatformName>

Which is jolly good until you get these ridiculous warnings:

warning VSD102: The type Microsoft.WindowsCE.Forms.HardwareButton is not supported in this platform.
warning VSD102: The type Microsoft.WindowsCE.Forms.Notification is not supported in this platform.

Then, as an intelligent developer, you do what comes naturally: you try to suppress those warnings.  Except you can’t!  /nowarn does not work with VSD102!  It only works with CS-prefixed warnings!

Oh noes!

Well, lucky for you, I’ve been dicking around with the failure that is MSBuild all day.  I also found this page that details a lot of retardedness going on at the Visual Studio For Devices team.  It mentions this “platform verification” nonsense and says that the way to stop it is to manually edit %windir%\Microsoft.NET\Framework\[version]\Microsoft.CompactFramework.Common.Targets.

“NO!” I say.  That will not do.  I’m using a compile server that I don’t have control of.  And NO I will not reproduce your stupid targets file.

A little digging around in that file, however, finds this little gem that had plagued me for a month when I was looking into hi-resolution stuff:

<PropertyGroup>
<ShouldAddHighDPIResource Condition=”‘$(TargetExt)_and_$(HighDPIResAware)_and_$(Win32Resource)’==’.exe_and_true_and_’”>true</ShouldAddHighDPIResource>
<ShouldAddHighDPIResource Condition=”‘$(TargetExt)_and_$(HighDPIResAware)_and_$(Win32Resource)_and_$(PlatformFamilyName)’==’.exe_and__and__and_PocketPC’”>true</ShouldAddHighDPIResource>
<ShouldAddHighDPIResource Condition=”‘$(TargetFrameworkVersion)’==’v1.0′”>false</ShouldAddHighDPIResource>
</PropertyGroup>

<Target
Name=”AddHighDPIResource” Condition=”‘$(ShouldAddHighDPIResource)’==’true’”>
<AddHighDPIResource
Win32Resource=”$(Win32Resource)”
ApplicationIcon=”$(ApplicationIcon)”
OutputDirectory=”$(IntermediateOutputPath)”>
<Output TaskParameter=”Win32Resource” PropertyName=”Win32Resource” />
<Output TaskParameter=”ApplicationIcon” PropertyName=”ApplicationIcon” />
</AddHighDPIResource>
</Target>

Try googling HighDPIResAware.  You don’t find anything except a plagiarized build script.  But this is the key to all of our problems.  All you have to do is set this property to something, anything in your project file and you are good to go.  No platform warnings, no changing platforms, no hi-resolution resource crap compiling in without your consent.

tl;dr:

<PropertyGroup>
<HighDPIResAware>1</HighDPIResAware>
</PropertyGroup>

Half of the important terms in this article were not indexed by Google, so I hope to have helped a the few Pocket PC developers still out there who care.  Because problems relating to this issue have probably used more of my time than any other .NET CF issue.

Microsoft and all of their shills say that you can.  But you have to do it the “safe” way.  You see – once an Assembly is loaded into your AppDomain, it can never be unloaded.  They recommend this solution: load Assembly into NEW AppDomain and unload THAT AppDomain when you are finished with the Assembly. Which would be fine if: 1. it worked seamlessly, 2. it performed reasonably, and 3. it were implemented on the Compact Framework.

You see, in order for two AppDomains to communicate, objects are marshalled back and forth using various proxies and byte copying mechanisms.  Some of this works transparently, a lot of it just plain sucks.  You can find a good example of it at this website.

The whole idea was concocted by assholes.  “Sandbox!! You must sandbox teh code and keep it separate and blah di blah blah untrusted blah safe blah blah references blah blah.”  Nothing like a little piss in the sandbox.  Actually, their real reasoning is this:

1. First off, you are running that code in the app domain (duh!).  That means there are potentially call sites and call stacks with addresses in them that are expecting to keep working.  Have you ever gotten an access violation where your EIP points to 0x????????  That is an example where someone freed up a DLL, the pages got unmapped by the memory system, and then you tried to branch to it. [...] This tracking is handled today around an app domain boundary.  Tracking it at the assembly level becomes quite expensive.
2. Say you did manage to track all handles and references to already running code by an assembly.  [...]The JIT’d code is still allocated in the app domain loader heap [...] So this one is solvable and just falls into the work column with a small hit on allocation and jitted method locality (probably not enough to measure).
3. The final issue relates to code which has been loaded shared, otherwise more formally know as “domain neutral”  [...] On the other hand, the code must therefore be tracked in all app domains it has ever been loaded into before it can be freed.  With the current v1.0 and v1.1 product it is not even possible to unload domain neutral code because of these restrictions.

In other words:

1. We’re too fucking lazy to figure out an efficient way to produce a killer feature.
2. We’re too fucking lazy to actually do our job.
3. We’re too fucking lazy to enhance our product.

Seriously, this has been a problem for 5 years now.  It was easy as shit in C and C++ to write a plugin infrastructure – but now, because we have to be ‘safe’ we can’t do this?  For fucksake, I’ll mark my code as unsafe if I could just do this.  This is a step backward!  Modern programming languages have been able to handle plugins forever, but some genius decided to unnecessarily complicate things with AppDomain communication.

Go die and kill yourself, you silly fucks.