Tag Archives: C

My Microsoft internship interviews in Redmond

Before applying to Microsoft I had read every blog post I could find by past interns and intern candidates. Since I know I’m not alone I want to leave my own experience. The summery of my story is next summer I will be interning at Microsoft working in on Windows. The internship does not start for another 4 months but I am already very excited. This post should be long so if your busy or lazy you might want to read at a better time. Please do not stay awake past your bedtime reading everything you can about the internship and interviews; I did a few times and frequently regretted it in the next morning.

The next two cover the process before the Redmond interviews which in turn is the third section.

Applying at Campus Career Fair

You can apply either online or in person if Microsoft sends recruiters to your campus. If you get the chance to apply in-person you should jump on it. Microsoft’s recruiters were real engineers and a lot of fun to talk to. A few months ago I wrote about my application. One thing I should add is the on campus recruiters perform a resume screen before sending the collected resumes to Microsoft. At the Q&A session the recruiters held after the career fair they warned about dropping off resumes without chatting.

Reading in between the lines I think this means the recruiters were tasked with making recommendations. Without talking to you they can only go by your resume which is no better than submitting online.

On campus interview, aka first round interview

I also wrote a post on my first round interview. Overall at this stage I would worry about whiteboard coding and have a project you can talk passionately about. Also take the time to review as many problems online as you can. Microsoft says they want candidates passionate about tech and I do not think those are not fluff words. This does mean you need to worry about signalling your passion. Getting excited and animated is easy for me but I know many programmers are a lot more reserved. You might need to practice by talking with yourself. One extra warning: check your house for quiet roommates before entering into long & loud debates with yourself over technique subjects. Nothing is quite as awkward as discussing the merits of C++’s exception handling then turning a corner and running into your roommate.

After the first round interview I got an email of congratulations. About two weeks later someone contacted me with the interview date and arranged travel to Redmond.

Redmond Interviews, aka second round interviews

Finding out who I was interviewing with

Two days before I was to leave a third person emailed telling me who I would be interviewing with. Their email’s exact text was “Windows Windows Live”. Now if you are a non-Microsoft employee this means two exact things: 1, they made a typo and wrote Windows twice, and 2, I was interviewing with Windows Live. I later verified this conclusion with other interns. Since I was gunning for low level work to complement my prior experience I was disappointed.

Yet I was wrong. It turns out Windows Windows Live is Microspeak, jargon specific to Microsoft. Since intern candidates are by definition not working at Microsoft you can imagine why we would get confused by this Microspeak. What Windows Windows Live is supposed to mean is Windows & Windows Live, which is a division of Microsoft.

It may seem like a minor issue but for the few hours it took to discover the misunderstanding my enthusiasm was killed. I was still happy with the chance to interview but working outside of my existing interests wasn’t very appealing.

Flying to Seattle for the Interviews

Below is a photo I took the night I flew out. There is nothing special about the photo, this is Calgary’s natural state. By this time of year the concept of a room temperture outside is foreign. The snow bleaches the landscape a cold white. The occasional chinook may melt the snow but this serves only as torture by simulating the beginning of winter, again.

Now here it is before the flight, at 18:00. We do not get very much sun during winter.

And for comparison here is Seattle before my flight home:

When I landed in Seattle I could smell the air, and it was sweet. I thought I might have been smelling spilled oil or other plane liquids but the sweet smell carried on into the city!

It did rain over my stay but that was not enough to dampen my enthusiasm to Seattle. Stepping off the plane was like time travelling five months forward to a none frozen Calgary.

Both my way there and my way back was quite painless. Microsoft arranged for a towncar to pick me up at the airport and even provided a Taxi voucher for the way back to the airport from the hotel. It was only back in Calgary that I had to arrange my own transportation.

The reimbursement for my travel and food expensive was also painless. I have already received and cashed the check. They even provided an option to reimburse in Canadian dollars.

The stay

Microsoft booked me at the Westin in Bellevue. I must say the hotel was the nicest I’ve ever stayed in. For a bit I got worried Microsoft had mistaken me for a full time candidate since it was that nice.

Morning of the Interview

At point I had yet to meet a Microsoft employee. Everyone from the towncar driver to the hotel knew I was coming. It almost felt like Microsoft was masterminding everything, always in control but never appearing. Since I don’t travel often this made the trip much more relaxing.

12:00 was our departure time so I went down to the lobby at 11:30 hoping to meet some other candidates. At first there was just three of us. One New Yorker and an Ontarian. The New Yorker was interviewing with the Office division and the Ontarian with Servers & Tools. As more intern candidates piled into the lobby’s couches we found out that the Ontarian was vastly outnumbered. Everyone else was split between Windows & Windows Live and Office. All the candidates were Software Development Engineer candidates.

When 12:00 hit we all split up into buses based on interviewing division. The trip to Microsoft’s Redmond campus did not take long and we were soon at the main Windows & Windows Live building. After checking in and receiving name tags we moved to a large board room. This board room acted as our home base. In between interviews we all returned and had ~15 minutes to eat, chat, and rest up for the next interview.

Interviewing at Microsoft

The whole interview process was planned and scheduled. And when I say scheduled I mean we received a schedule:

After launch at 13:00 the interviews started. This was both the most interesting portion of the experience and the portion I can least talk about. Prior I had read most of Glassdoor’s interview reports but even so all the questions I was asked were new to me. I liked it that way since I could puzzle through the problems and ask real questions. One interesting fact was that all candidates were asked questions from the same question pool. Thus after the interviews we all chatted about the questions.

For the first interview my interviewer was from Visual Studios.To my despair I missed the solution by a mile. Here I’ve gone and flown to another country and I’m grasping at straws on the first question. I was humbled and just a bit depressed. To my luck this question was a tricky problem for most people. One of the Office candidates told me the official answer and I think I might have been close without realizing it.

The second interview went better but not great. My interviewer was from the Internet Explorer team and picked a question from outside my area of expertise and had the grace to tell me so. This made me feel better about not completing the entire question. My implementation was going fine until it wasn’t. One of the three cases I needed to handle required me to break a critical assumption I made at the top of my implementation. This was after taking a decent quantity of time to come up with my algorithm. Still I am proud of how far I did get even if I did not very far at all.

Interview number three was the most awesome. I had an interviewer from the Windows Kernel! He even had a massive unix hacker beard! To be more specific he worked on the filesystem. His question style was to look over your resume, pick a term, then ask you “What is <term>?”. If you were not excepting this, like I wasn’t, then you’ll be taken aback. Still he was a lot of fun to talk to and had no problem with me referring back to linux for the technical questions.

My final and forth interviewer was from Sustained Engineering and will be my boss this summer. This interview went the smoothest of all. I found the “perfect” solution and implemented it with only one bug resulting from my being clever. In hindsight a bug due to over cleverness is the exact *wrong* thing to do when your interviewer has to deal with the resulting codebase. My clever trick was to use bit manipulation to avoid a conditional branch which I then not mixed up with negation in two’s complement.

In every interview I had a real chance to ask questions and got honest answers. They even stopped my problem solving to leave time for questions. The interviews themselves were held in various unused offices. The offices had two chairs, a desk, and one or more whiteboards. The occupied offices I walked past were well outfitted for programming. As a bonus there was even a pile of old unused computer parts and monitors sitting in the larger corridor. I can only assume that this pile bodes well for a non-authoritarian office environment.

On a fun note one of the interviewers used a prototype Surface Pro, this was a few days after the official announcement. I only noticed it when he closed the kickstand and I got a glimpse of the distinctive “128GB” labelling. He said the battery worked very well for his needs. Note: I’m not sure if this information counts as confidential or marketing.

Results

After the interviews we piled back onto buses and went to a Microsoft showroom/waiting room. There was a Microsoft Pixelsense, Microsoft Xboxes, Microsoft Phones, and Microsoft snacks. To be honest I don’t think Microsoft designed the snacks; but they did provide them. There was pop in a mini ridge and bowls of candy everywhere. While waiting for the results we played tower defence on the Pixelsense, snacked, or chatted. Some candidates browsed wikipedia for sights to visit the next day.

About an hour later the first candidate was given his results. He had not been accepted. Soon after I was called away.

Imagine my excitement when the recruiter said “Congratulations!”. Yup, I managed to get the internship despite not solving all the questions and failing the first interview.

Since multiple recruiters were delivering the news in parallel when I got back to the waiting room only three candidates were left. Me and another guy took an SUV back to the Westin and I went off on my own to find a McDonalds. Other candidates, successful or not, went off to max their food budget. I would have went with them but I wanted to skype my parents.

Offer Details

Microsoft said not to disclose the exact details. What I will say is that it is high, as in rivalling the introductory full time offer territory. The offer should be equivalent or superior to Google’s. The base monthly salary should be similar but Microsoft subsidizes housing. I also checked with a friend who got a SDET internship that the offer does not discriminate between development and testing. I do not know the Project Manager Intern’s offer was different.

One thing to note is the contract contains a non-compete clause: I cannot work on any software that competes with any of Microsoft’s products for six months after the internship. In a nice aspect the contract does allow personal projects provided they are unrelated to my Microsoft work.

Final Thoughts

I am very excited for this summer.

That Microsoft has no problem with my Linux heavy experience is impressive. I hope this means Microsoft has changed and is not the insular monolith I used to hear about. One of the candidates with an offer even wore his Google backpack from his last summer’s internship for the interview, and no chairs were thrown at him!

Update 2013-10: If you are still interested please consider reading through the overview of my internship.

My Microsoft internship university campus interview experience

8 Replies

Following on from the recruiting event I mentioned Microsoft emailed me for an on campus interview. Thus I had succeed on the resume screening and my next challenge was a half hour in-person interview.

Microsoft flew in two engineers for two days of interviews. We were able to schedule our own interviews through a webapp. Four hours after the interview invitation email I logged into the app and saw only ~5 interview slots blocked off. Since there was capacity for ~48 interviews I had my pick of the prime timeslots.

Worrying over meta interview tactics is distracting yet fun. When is the optimal time to interview? Right after lunch? Definitely not later in the day, but could you interview too early?

After thinking on it for 10 seconds I picked the very FIRST slot on the first day. The decision became much easier when I realized earlier meant less waiting.

The early timeslot also gave me the chance to arrive 30 minutes early, meet the interviewer, and help setup the interview room. With blatant disregard to notions such as “fairness” I also extracted extra interview time with a 10 minute early start.

In my defence I really like interviewing. I also like exams and interviews are like my favourite kind of exam. You go in with nothing to fall back on and you must think your way to the answer. I can only assume this is not a common attitude since my classmates insist on spoiling the fun by studying before exams. Of course Software Engineering wise this attitude would lead to disasterious code duplication and sub-optimal algorithms so I reserve it to exams and interviews.

Interviewer wise the engineer started by classifying my experience and preference: “Configuration-less printing” + “Low & Medium level Systems”. The low level systems might be a bit to generous. When I mentioned my preference he gave me the distinct impression he expected a more popular Microsoft project. I can only imagine how many times people have asked for the Xbox team or The New New thing.

Next he asked a super common open ended question. Every recruiter I had talked to so far had mentioned how “passion” was very important, and this was the question where he want to see it. In anticipation I had a very passionate tale about a yet-announced personal project. This project includes a custom designed algorithm and cool web technologies so it was perfect for the question.

After this came a code design question, take a sub-optimal situation and design the best hacked together work around. The hypothetical situation involved lists. Out of my three interviewing experiences two have featured linked lists. I love this since I spent half a summer using linked lists in libjtapi. Yet I cannot help but worry I’m being mollycoddled, where are the difficult tree and graph problems I’ve been worrying over? My pet theory is that the interviews so far have not been comfortable evaluating C code so they stick to simple problems for their own sake.

Once we agreed on a semi-optimal solution he asked me to code it up. This was uneventful, C is my most favoritist language so I wrote it top to bottom without any syntax errors. We discussed an error case I wasn’t checking for. I prefer things to segfault if the calling function acts silly and passes in a NULL parameter, no risk of someone ignoring an error code. NULL pointers are not something that tend to occur at run time. If you are calling with a NULL pointer it is because you messed up, hiding that is dangerous. Of course I didn’t mention this since we had no time to explore the justification.

This brought the interview to an end, time really does fly when you are enjoying yourself. I thanked him and headed to class.

Overall I though it went well, no further interviews yet but its only been a week.

Update 2012-10-22: I got the next interview set, the in Redmond ones!

Update 2013-10: If you are still interested please consider reading through the overview of my internship.

My Google internship interview #1 a post-mortem + what I learned

8 Replies

This post is about to partake in considerable navel gazing. An interview is a product of the company combined with the interviewer. Thus I am going to present my interview experience and the leasons I learned, your mileage may vary.

TL;DR: My interview was stressful, super fun, and a great learning experience. I failed to get an offer but that’s A’Okay.

昔々 – In the beginning

Submitting a resume to Google is a non-trivial action for someone like me, a human. I have self-doubts, I know all my faults and oh-boy are they faulty faults. I only started programming when I was 17. I don’t know Ruby, or Node.js, or Haskell. I’ve never written a multi-threaded application. Just yesterday I wrote something incorrect, on the internet. I am attending my city’s university, not even my province’s much less the ivy league. The first open source project I released included a remote execution vulnerability that took me a two weeks to notice.

And then I compare myself to a friend from high school. Before I knew for loops by heart he was contributing to CLANG. The summer after high school while I was learning PHP, he was doing Google Summer of Code. He then enrolled in Canada’s premier Comp Sci university. The next year while I was doing GSoC he was interning at Google. If Google has people like those why ever would they give me the time of day?

Yet Google sells applying hard. They send recruiters to universities. Everywhere online Googlers repeat the mantra, “Google is awesome and you should apply, even if you are not awesome.”. Even the GSoC mailing list received an invitation to apply.

Google has put more effort into selling me on the idea of applying than any other company ever.

Yet it took 6 months after they gave me a pizza for me to build enough courage and click the apply button.

Note to past self: It is normal to be nervous about applying, but you should apply anyway. Nothing bad will happen and you can always write a blog post about it.

時間が掛かる – The waiting

Pressing the apply button is the very definition of anti-climatic. I had spent months thinking about it. I had spent days working on my resume. I had spent an integer multiple of 30 minutes double checking my application. This climax resulted in a simple email in my inbox.

Notice how nowhere do they use the word ‘fastly’. This is for two obvious reasons:

Fastly is not an English word, I just made it up
The process is not fast

I cannot fault Google for the speed but I would be dishonest to not mention that at this point you need to do two things:

Mark your calender for one month from the date you applied
Forget that you applied

When I was younger I had a habit of buying cheap trinkets from China. Shipping was free but took months. My first few purchases drove me crazy. They would take weeks to even get shipped and even longer to reach my doorstep. Yet by about the seventh shipment my attitude had changed. I would buy things and forget about them. I had learned patience.

Two weeks later and 1.5 weeks after I had forgotten; I received feedback. I got an interview!

Note to past self: Even in the best case you will be waiting. PS: Buy fewer trinkets.

準備 – The preparing

I’m not sure what I was thinking. I knew when I applied what my timetable was: busy. I was taking a year’s worth of Japanese classes in 6 weeks. Every day we covered a week’s worth of material. I loved it. Yet that is perhaps not the best time to study for an interview. I asked my recruiter to schedule the interview right after my class ended.

This gave me time to study. Sure I had studied even before applying. Sure I had taken my Data & Algo course. None of that is ever enough, I /need(ed)?/ to improve.

I based my study on this influence blog post: http://steve-yegge.blogspot.ca/2008/03/get-that-job-at-google.html

I had bought the algo textbook he recommended and my goal was to read all of it. I had two weeks to read half of it which I did manage.

Note to past self: 01: studyMore(); 02: goto 01;

本物 – The real thing

Given any arbitrary finite number, N, and an always incrementing variable, I, there will always come a point when I >= N. I had set my interview two weeks into the future but time can only slow so much. At some point my interview would occur, a mathematical inevitability. My estimate was that this would occur in two weeks right at 10am.

An obvious conclusion, yet like so many other attempts to apply simple math to the real world it was incorrect.

Once the world’s clocks, adjusted for timezones, hit 10am my interview failed to occur. Nothing had happened, my phone did not ring and my inbox was empty. My interviewer did not show up.

I waited until 10:05am and emailed my recruiter. After a further 3 minutes of panic my she replied, she was having troubles contacting my interview. This was my best case scenario. You see in those seven minutes I had hypothesized several other scenarios:

It was all a dream
California had been blown up to turn Naveda into beach front property
The tech bubble had popped that morning and Google had no longer a need for interns

Instead it was traffic. My interview was stuck in traffic. Truly the better scenario.

Tip to past self: If an event has a X% chance of occurring, where X > 0, that means it might occur to YOU. And if it does occur the event will not be as bad as you imagine.

Thus my first interview became my second interview and I received an unexpected 40 minute break to cook some food.

Again since 40 < ∞ the story is not over.

Now I have to ask: have you ever heard of a phone interview done over IM? I had not, but I had heard of consumer VOIP not working. Skype is notorious for this. Yet I had two constraints:

My smartphone has a prepaid SIM, calls costs 25 cents per minute
My student housing has a nine year old cordless phone, it’s battery will not last 10 minutes

In my freelance work most communication is over email or Skype if the client wants to talk. This is the 21st century after all. With that in my mind I asked my recruiter to accommodate me, I wanted to do the interview over Google Talk.

Google Talk of course because Skype would be insulting, plus it might not work. As it turns out Google Talk also has a slight chance of not working, about 60%. My first interviewer was not able to get Google Talk working under his Chrome OS installation. I want to believe that this is because he was a Chrome OS developer running some bleeding edge version, and since we have no evidence otherwise lets just pretend that was the case and move on.

Thus my first interview took place over IM and a shared Google Doc. After 30 minutes of not-interviewing we fell back to pure text communication. For the next <30 minutes I programmed in the Google Doc and tried to explain my thinking in comments. Things went ok. I did have a massive bug in my program but I managed to be the one to find it. At first he did not see the bug but once I explained the edge case he agreed my code was bad. Overall it was not much different from regular programming.

To be honest I think that interview was a wash. I sure know that I would have ‘no-hired’ myself if I was in his position. I had failed to impress and while I can blame tech, the reality is that it is my job to impress.

Tip to past self: You must use a regular phone. VOIP is not an option no matter how attractive.

I have to give credit to my second interviewer. He set aside time before the interview to setup Google Talk. We still lost a good 20 minutes out of the hour but we were able to have a real conversation.

Now I am about to do something I maybe should not do. I am about to tell you one of his interview questions. I promised Google I would not, but here is why I am going to do so anyway:

The question is only applicable to some people
There is no right answer to this question
The people to whom this question apply should ask themselves it

He asked me why I liked Open Source. I was taken aback, I had no answer. I dedicate many hours writing open source. Over the summer I earn less than my classmates because I want to work on Open Source. I will use an inferior Open Source program to a superior proprietary one. I avoid non-open source programming languages like the plague.

I know I like Open Source, that is not in question. Yet the question of why is one I did not know. I tried to save face by reciting the standard lines. You know the ones about many eyes, about freedom, and about self selection. Yet I know those are not MY reasons for liking Open Source.

After the interview I thought and determined my true why. If you are curious you can check my resume, right under the ‘Open Source’ header.

Note to past self: Self reflect on why you like Open Source

His next questions were classic algo questions. At the time I did not realize it at the time but he even asked me how I would design assembling Google’s search results. Since this is perhaps the second most time critical piece of software on the internet I feel embarrassed I got annoyed at his insistence on absolute performance. I never said anything of course and my final design was optimal, I just could not remember the details of the key data structure, only the name.

Since I cannot talk in detail about the question that triggered it I will have to add the following tip without backing detail.

Tip to past self: Treat all numbers like variables. They may be presented as finite numbers but your interviewer is thinking of them more general. While technically sorting 10,000 strings is O(1), always pretend that they asked about sorting N strings.

One implication of the above is that I got into an argument with the interview. I assure you, I did no such thing. Instead I realized later that me and my interviewer had understood the question differently.

After that question we did some programming and I figured out that my interviewer was a Linux Kernel Developer, the braces of his function blocks gave it away. This gave me an opportunity to thank him for his kernel work after the interview ended, which I think was only fair considering I had just consumed his entire productive morning.

On that note my interviews were over. A few days later I got the standard email from Google about not fitting any of their current roles. Before I knew this was the standard email I thought maybe I had made a mistake doing the interview in C. Google only uses C for a few projects, the Kernel and Android, both of which I would not be good enough to work on. Thus I feared I had done it:

I had shot myself in the foot with C.

Which is not the case, I was just not good enough. Still that would have made a great story eh?

追記 – Final comments

I am thankful for knowing people better than me. Without my friend having done a Google Internship I would not have considered it. Without smarter classmates I would slack. I am on a constant search for people who are better than me yet humble about it. I enjoy being around them and I enjoy the effect they have on my motivation. I know Google has people better than me and I also know the company is always encouraging people to apply which sounds rather humble. Thus I will be applying again, and then again. At this point Google should consider saving some money and blacklisting me.

The second hardest bug I have ever encountered, an essay on C: The Portable Assembly

5 Replies

C is a special language. I’ve always understood that but I used to think it was in reference to C’s history. Reading tutorials as an intrepid learner I kept coming across references to C as the syntactical parent to X language’s syntax. What I did not know is that C is fundamentally different from all other modern languages.

C is a portable assembly, to borrow a common description. I’ve heard people refute the description, citing C’s expressive power and structured coding. I am forced to agree with their argument but not their conclusion. C does indeed look nothing like assembly yet that difference is only on the surface, and the surface is easy to scratch through. C abstracts away the triviality of assembly but leaves the programmer exposed to the intricacies.

For generic programming C++ has templates, Java has Generics, yet C only has void pointers. Void pointers are a curtain beyond which the compiler cannot perform any type checking. For libjtapi I needed a generic dictionary data structure, which meant I needed void pointers. Thus over the weekend I found myself programming in C but debugging like I was in assembly.

The bug itself is less significant that what it took to debug. A story which might illustrate why C is like no other modern language.

Of course the bug was my fault. There is a saying that poor programmers doubt their tools, something I have seen before. Despite knowing this truth I was almost ready to test my code with a different compiler thinking GCC at fault.

If I ignored the bug it disappeared, that is not how bugs are supposed to work. A Heisenbug.

The bug was sneaky, it hid itself. If I were to comment out the error case that checked for it then of course libjtapi would never complain, that is an obvious result. The logical result of doing so would be unreported data loss. That is how bugs work. Yet if I did comment out the check everything worked as intended and no data was lost. Line for line the input was the same as the output, just as it should be.

A next logical step would be tracing print statements showing what was occurring. In modern languages you can even dump complete data structures, in C you have to settle for printing primitives like integers. Yet even a single print statement would throw the code into a state of data loss. Data that was supposed to be in a dictionary was being reported non-existent between two layers of abstraction.

I needed to find the bug’s on/off switch. Knowing what caused the bug means I would know the bug’s type. It means I would know where to look.

My next step was to add intention time delay. A sleep(1), which pauses for one second, in the right spot would cause breakage in a different dictionary, progress. A sleep(0.001) call would bring us back to the land of functionality, more progress. I should make a side note here, this was not the next logical step of debugging. Libjtapi is not multi-threaded and memory writes are synchronous, thus it was impossible that time might cause the bug.Yet my brain getting ever more tired was not willing to accept this.

In Calgary darkness is warded off by city lights

Programming at night is often a bad idea, double so for debugging. By now it was getting late and this bug was becoming mythical. The simple act of checking made it leap into existence and voodoo acts of timing would ward it off. A sense of dread took form, I knew this type of bug from assembly, my bug was somehow related to the intricacies of hardware. No amount of stackoverflow is doing to solve a fundamental misunderstanding of how my hardware works.

In the morning I took a different approach, maybe some variable were not getting initialized. Initializing one variable appeared to yield progress, everything worked. By know I was getting wise to the bug’s methods. I proceeded to add explicit initialization to other variables. The code responded in turn to switch between breaking in two places and not breaking anywhere.

This was real progress. My changes amounted to consuming room in lower memory space, expanding my binary. Which pushed all memory addresses, and thus pointers, up in memory. Thus the bug was somehow related to memory alignment. Memory alignment is a hardware restriction, that datatypes can only be read from an address which is divisible by N, where N is based on the datatype’s size. Some void pointer was pointing to an address illegitimate for the datatype.

Libjtapi keeps metadata in arrays prior to dynamic caching

The question thus became which pointer? Before I could answer that I needed to identify the structure into which said pointer pointed.

With the intention of narrowing the candidates I added global char variables to pad the binary. This let me cycle though the bug’s three states. The idea being to find some number with which to identify the structure’s size, and it worked. I got 3. But before I could put that into use I got the best hint possible, libjtapi started to segfault. The illegitimate pointer was getting nudged just outside the boundary of libjtapi’s mapped memory. With this giant arrow I squashed the bug with ease.

You can see the current fixed code at the top of this post. C is not at fault for the bug, I am. Yet it is not to C’s credit that I lost a day of productivity. Sure an experienced C programmer could have avoided the bug. They would have noticed the invalid void cast that caused it. Yet so would an experienced assembly programer.

libjtapi data can now do a round trip

Daniel

Game Programmer