Wednesday, July 18, 2012

Never fly Philippine Airlines

It took some doing, but Philippine Airlines have supplanted United in the "I will never fly them again unless there is no other choice" stakes.

On our most recent trip, three out of four legs of the journey were just too unpleasant, and while the last helped to smooth over the annoyance, the sum total was best summed up by Catriona who said "Dad, next time we fly, can we *not* go with the cheap airline?"

Picture this: You get onto a plane, about to take a 10 hour flight, expecting to see those in-seat monitors.  What you get is a poorly focussed overhead screen.  And a bunch of children looking really disappointed already.

The announcement comes over to "please close your windows - if you want to read, turn on your overhead lights".  You push the button.  Nothing happens.  You sit in the dark with your Kindle wondering how you're going to kill the next 10 hours.

You open the window and let the light in. A flight attendant comes and asks you to close it.  You explain that the light doesn't work.  She goes away.

The purser comes and asks you to close it.  You explain that the light doesn't work.  He shrugs.  You show him that in fact the light control actually comes out of the seat showing exposed wiring.  He laughs and goes away.  You hope that the wiring in the cockpit is in better condition.

Repeat for two more flight attendants.

For an hour you try to watch the blotchy screen showing some movie.  The movie stops.  And restarts from the beginning.  This happens several times during the flight.  They do show snippets of an insane American game show where people get hurt trying to climb over/under/through a watery obstacle course.

After 10 hours, you get off in Manila.  You are escorted up to the departures lounge, and go through security having your bags and shoes X-rayed, and being patted down.  Loo break, have a tiny ice-cream, then go to the gate (approximately 20m away from where you were last scanned) where you have to go through security again, having your bags X-rayed and being patted down.  Presumably this is because you might have visited the gun dealer in the departure lounge.  At least, you can keep your shoes on this time.

So, now you are in the "secure area" - that is, a part of the same floor that's cordoned off with those ribbons you see in bank queues. Once inside the "secure area", you realise that there are no seats left so you sit on the marble floor, only to realise that the airport roof is leaking and the floor is wet.  But it's ok, that's to make sure you don't dehydrate -- it must be, after all, it's the only source of water you have access to until your flight.  Unless you want to go through security again.  Remember, you can't bring more than 100ml into the "secure area" so don't think about going out and buying drinks for the kids.

Still, at least this next Manila to Los Angeles flight will have personal screens, won't it?  No, you probably only wanted to just sleep anyway.  This time we're split across three rows, with me behind the three kids and Pauline somewhere up frontish.  I get to share the row with a couple who were, well, large.  For the entire trip, the voice in my head was that of the male hippo in Madagascar 2 saying "Girl, you're large. You're chunky!"

(realise that I've been switching from second person to first person - give up dreams of being a novelist)

But you're in LA now - have a holiday, and try not to think about the flight home.  If you have to think about Manila, think about how cheap the ice-creams were.

Legoland.
Disneyland.
Fireworks in a carpark on July 4th.
Universal Studios.
Legoland again.
Fly to Washington.
Smithsonian x 2
Too many burgers, too many cokes, this is holiday living.
Drive to Pennsylvania
Climbed on by niece and nephew

Too soon it's over and you are winging back from Washington to LAX arriving at about 2:30pm and having to wait till 10:30pm, thinking "I'll check the suitcases and then grab a bus somewhere outside the airport".  Bzzzt, sorry, Philippine Airlines don't begin checking in until 6:45pm.  Ok, this one isn't completely their fault but if the whole trip had been with them, I'd have been able to check the bags in in Washington.

Ok, we're back - side trip was acceptable though it was a little tricky dragging 3 suitcases and 5 people each with backpacks onto a peak-hour city bus.  Again, can't blame the airline for that.

At about 10:45, learn that "because the plane is lighter than we thought, we don't want to stop in Guam to refuel".  "Hooray" shouts the crowd.  "... so, we'll be delaying the flight until 1:30am so that when we get to Manila Airport it will actually be open."   "Boo!" shouts the crowd.  "... so, here is a $12 voucher that you can use at any of two eateries here in no-mans-land behind security -- no, they won't work anywhere else".

(Hmmm, and yet the airports Facebook page says "always open" - sigh)

Get on the plane and discover that the little man at checkin who told us that the last side-row of seats reclines, was lying.  They don't.  They would block the exit door. He had deliberately moved us there to keep us altogether and we explicitly said that we would only go there if they reclined.  So he said "sure they do".  First rule of airlines - get the passenger to be someone else's problem, preferably at another airport.

We complain to the purser and get the girls moved forward about 40 rows, leaving us boys at the back.  Next to a walrus.  I don't know what else to say, just try to imagine someone who can snore loud enough to be heard over an airplane engine.  Thomas can't take it and moves forward with the girls, leaving Jonathan and I with more room.  And a noisy walrus who, to be fair, eventually shut the hell up.  But that just made it easier to hear the scary rattling noises from above.

Try to lift the arm rest to use that extra space?  Aha, no, they have that covered too, they only raise about 2/3 of the way making it impossible to spread out.

Well, at least this time the plane has those little screens.  Look, Movies and TV. Hmmm, movies aren't anything special, what do they have on the TV - *one* program.  One! And for irony, it's "a documentary on aviation technology".  After the flight, you learn that in fact the people over on the right hand side of the plane had dozens of TV shows to watch.  Or perhaps it was "front" vs "back".

Watch a couple of movies. This part was ok.  But it's what we were expecting on every leg.

When the flight is just about over, we discover that in fact when they moved the girls, there were three empty seats behind them - they could have moved us all, they just didn't think we'd want to.

Back at Manila.  Back to double-goes on the security ride.  At least, this time it wasn't raining.

Notice that the security area has been set up so that the guy looking at the X-ray screen has to shade it with his hand the entire day, because they placed the screen such that the sun shines directly on it through wall-to-ceiling windows - what a shame they couldn't have anticipated, while designing the airport, that the sun actually shines.  This just reinforces the notion that all of this security crap is based on the notion that the guy before you was incompetent.  Not to mention the tautological sign that justifies it by saying "Philippine law requires that all bags be inspected when passing through inspection points".  So, if they hadn't put an inspection point in, there would have been no need for an inspection point. "It's a bypass, ya gotta build bypasses".

One last plane.  One last chance for reasonable entertainment.  Why does the screen say TV but doesn't mention Movies?  And why is there so much "Glee" in the TV section?  After four reboots (did you know those things run Linux? We do now), the Movies actually show up.  So, the final leg of the trip is tolerable.  Not surprisingly, it was the shortest of the bunch at less than eight hours (Manila to Sydney is faster because it's downhill all the way).

Oh, by the way, you know how nice a warm pork bun can be?  Not surprisingly, the "warm" isn't optional - a cold pork bun snack really doesn't do anything for me, but they served it anyway.

All told, there weren't any catastrophes, no lost bags, no falling out of the sky. Just a series of unpleasant experiences which left you with the feeling that "this is an airline that is just a bit manky".

Your mileage may vary.  But I've flown Singapore Airlines, I've flown Air New Zealand, I know it can be done a lot better than Philippine Airlines did on four flights out of four.

Friday, April 6, 2012

AutoCAD 2013 and LiteHtml.dll

Installing AutoCAD 2013 is complaining about LiteHtml.dll. Whats the story?

I can't say for sure, but I think you'll find that you have an over zealous system administrator who decided to deploy a security system that can only have been designed by chimps, then implemented by the most idiotic intern at Microsoft.

Go read this Knowledge Base article: http://support.microsoft.com/kb/2264107

Can you believe that? Some idiot thinks that DLLs are always completely self-contained, that no-one other than Microsoft might build an application where DLL1 depends on DLL2 which happens to be delivered as part of the same product.

This wouldn't be so bad if the numb nuts that actually implemented the security feature actually knew what they were doing. It appears that setting the CWDIllegalInDllSearch entry does not "omit the current directory from the search". Instead, it changes the order it considers directories. If a matching DLL is in the current directory, it halts the scan immediately. Doesn't check that the DLL would have been found via the official path strategy - it just stops.

Now, it's fine to say "but this is a vector for malware". Sure it is, but if someone can install a DLL into your application directory, then they can change your application as well, so this hack prevents *nothing*.

In case one of the afore-mentioned chimps is listening, they should find someone smarter than they are and ask what the letters in DLL mean. Dynamic Link Library. Suggesting that you can work around the problems this security setting causes by explicitly (and manually) loading the libraries you need with LoadLibrary() misses the point that there are no published APIs that tell you what libraries a specific DLL needs. If I have to write my app so that it analyses every DLL it loads, then every DLL that *they* load, recursing till I hit metal, then there is no point in actually *linking* against those libraries.

Thursday, May 19, 2011

Grandma's Apple Pie (as dictated by Mum)

Short Crust Pastry


Blend 125g butter, 125g plain flour and 125g self raising flour in a kitchen whiz.

Add 2 tablespoons of caster sugar and blend.

Add 1 egg yolk and combine.

Add 2-3 tablespoons of ice water (until the pastry almost combines)

Press pastry into a ball, then separate into 2/3 and 1/3 disks flattened out.

Wrap in plastic and chill for 60 minutes.


Apple Filling


Peel, core and slice 5-6 large Granny Smith Apples. Add 1 lemon, cut into quarters. Add 1/4 cup water (up to 1/2 cup).

Bring to boil and cook till softened. Add 1/2 cup sugar and stir until dissolved. Leave till cold.

Put pastry in tin and add cold apple, being sure to remove lemon. Cover with pastry. Brush the top with egg white, then sprinkle with caster sugar.


Cook at 220C for 10-15 minutes.

Turn oven down to 180C and cook for 25-20 minutes (ie, make the total oven time about 35 minutes).

Sunday, February 27, 2011

Samba NAS and error code -36

I just bought a Seagate GoFlex Home NAS and was wanting to backup a bunch of files to it. I ran their installer, installed all their recommended tools, configured the server, and got a Folder on my desktop representing the "GoFlex Home Public" folder on the server.

The first thing I tried to backup was their installation software, and I got this:

The Finder can’t complete the operation because some data in “some folder” can’t be read or written.
(Error code -36)

It's taken me several hours and lots of unsuccessful internet trawling to finally work out what the workaround is, so I figure its worth a post here where Google can find it for the next guy.

The problem appears to be related to the use of extended attributes, which Snow Leopard loves to attach to files these days. I believe that there is some sort of problem writing files with the com.apple.quarantine attribute to Samba mounted disks. Whilst you can try to use xattr -d to remove those attributes from your files, its tedious and very error prone.

Similarly, I found that sometimes files got stuck on the drive - you couldn't remove them, if you tried (in the terminal) you'd get permission errors. Nothing, sudo included, would allow you to fix the permissions. Yet looking in a terminal window with /bin/ls, they looked fine.

Short answer: Don't use the GoFlex Home Agent to mount network folders.

This always uses the smb: protocol to access the server. Instead, use the "Connect to server..." command on the "Go" menu in the finder, and explicitly specify that you want to use the afp: protocol instead.

Once I switched to using afp:, all of the spurious errors went away. I was able to delete all the temporarily stuck files, and I could copy whatever I liked onto the drive, regardless of the extra attributes.

Strangely enough, when I then tried out the Memeo Backup that Seagate include in the package, it warned me that my backup volume is afp: and I should use smb: instead. Yeah right. However, it looks like one reason they recommend smb: is that the afp: volume didn't seem to auto-mount when I went back in - I had to mount it for them.

Update:

Alternately, you can just wait for Apple to release OSX 10.6.7 which "resolves an issue when transferring files to certain SMB servers". Clearly, this blog post blowing the whole issue wide open had them scared and they realised they had to fix it pronto, or face my scathing posts.

Update 2:

Hmmm, despite it "mostly" working, I keep getting errors from Time Machine saying it was unable to complete the backup - it looks to me like it fails if it has to mount the drive itself.

Moral: do not buy this drive if you want to use it for Time Machine backups.

Saturday, November 27, 2010

Why are my zeroes behaving like ones?

Guess the output of this program:

C:\>type x.c
#include <stdio.h>
#define ZERO 0
#define P(x) printf("x=%d",x)
main()
{
  P(ZERO);
}

C:\>.\x.exe
x=1

Duh, what?

Ok, I cheated, I didn't show you the stupid compiler option I managed to pass through the use of a slightly buggy makefile.


C:\>cl /D0 x.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

x.c
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:x.exe
x.obj

For those who don't memorise command-lines, that /D0 essentially is instructing the compiler to "define a value for the symbol 0" and the default value for definitions is "1".

Yes, the Microsoft VC90 compiler actually allows you to redefine the value of INTEGER tokens in your source code. Same thing happens at VC100.

C:\>cl /D0 x.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

x.c
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.

/out:x.exe
x.obj

C:\>.\x.exe
x=1

It could be argued that it only shows up if you have one preprocessor macro using the value of another preprocessor macro, and you have to use an unlikely command-line option, so its not that tragic. But seriously guys, Apple catches you doing that sort of stupid thing at command-line parsing time...

jeff$ cc -D0 x.c
<command-line>: error: macro names must be identifiers

... and those of that that grew up with ANSI-C use macros like this all the time.

#define NAME(l) l[0]
#define ADDR(l) l[1]
#define TYPE(l) l[2]

Having those 0, 1 and 2 become subject to the whim of the command-line is unthinkable.

This all came about because of a Python-generated command line. I thought I was creating

CL /DOPTION0 x.c

but a bug meant I created this instead:

CL /DO /DP /DT /DI /DO /DN /D0 x.c

So I'm a lot more careful now.

Someone did point out to me that "All computer programs are just 0s and 1s. Looks like this one was just 1s".

Computer geek humor.

Thursday, July 2, 2009

.NET corrupts heap when marshalling LPSTR

(Hi Lizzie)

I've just spent the best part of a week trying to track down why my bridge from C# to C++ was working on Windows XP but crashing sporadically on Windows 7, and the answer is that .NET marshalling is trickier than you think for strings.

Essentially, I had this:

[DllImport("mydll.dll",CharSet=Ansi,CallingConvention=Cdecl)]
[MarshalAs(UnmanagedType.LPStr)]
private static extern String LookupCorrespondingString(Int32 key);


and in the DLL, I had

__declspec(dllexport) const char *LookupCorrespondingString(int key);

Whenever I called this, it would get all the way into my DLL, I could tell it was going to return a value, but during the return operation, it would crash. When I ran it in the debugger, I got output messages about how memory was being free'd into the wrong heap.

Eventually I found this article:
https://blogs.msdn.com/dsvc/archive/2009/06/22/troubleshooting-pinvoke-related-issues.aspx
which contained the useful quote (emphasis mine):
When a string buffer allocated by native code is marshaled to managed code, CLR Interop marshaller will allocate a managed string object and copy the contents of native buffer to the managed string object. Now in order to prevent a potential memory leak, CLR Interop Marshaller will try to free allocated native memory. It does so by calling CoTaskMemFree. The decision to call CoTaskMemFree is by-design. This can at times lead to crash, if memory was allocated by the called-native function using any API other than CoTaskMemAlloc family of API’s as custom allocators may allocate on different heaps.
And there was the answer. .NET was freeing the block of memory I had passed to it to help me "prevent a potential leak". The problem being the lack of ability to communicate the 'const-ness' of the underlying DLL entry point's return value in the MarshalAs() attribute.

The solution was to declare the entry point differently:

[DllImport("mydll.dll",CharSet=Ansi,CallingConvention=Cdecl)]
private static extern IntPtr LookupCorrespondingString(Int32 key);


and then when I call it, do the marshalling explicitly.

String s = Marshal.PtrToStringAnsi( LookupCorrespondingString(k) );

After I bitched and moaned about how this stuff isn't documented anywhere, Manish Jawa kindly pointed out that it is, in fact, documented in the very first sentence on this page: http://msdn.microsoft.com/en-us/library/f1cf4kkz.aspx - you can't ask for more than that.

Actually, you can and they give it to you here: http://msdn.microsoft.com/en-us/library/x3txb6xc.aspx - the problem I was experiencing and its solution spelled out.

So, the moral of the story is: if you pass native strings to .NET via the marshalling interface, make sure you use IntPtr and PtrToStringAnsi() unless you want them to be free'd for you.

Wednesday, May 13, 2009

Embedding .NET in an otherwise native application

For reasons best known to the company I work for we embed the .NET CLR inside our otherwise native C++ MFC-based application, and for the last two weeks I've been trying to nail down why pretty much everything seems to work, except the windows where we embed the WebBrowser control via COM.  No matter what I tried, IOleObject::SetClientSite() would fail and the web browser would display as an empty white rectangle on the desktop instead of in our window.

This guy seemed to have a very similiar symptom, but no answer; however, it was a fair guess he had the same problem and it was something to do with threading.

One of the guys at AutoDESK Developer Support (thanks again) pointed out that the CLR initialises the main thread to use MTA (multi-thread-apartment) mode, whereas the WebBrowser control really only works with STA (single-thread-apartment) mode.  So, the solution was to ensure that I called CoInitialize(NULL) in our main thread before the CLR had a chance to mess things up.