Hello, I was browsing through older posts that deal with the painful issue of portability (http://www.keil.com/forum/docs/thread8109.asp). I was (and still am) a big advocate of programming as much as possible conforming to the C standard, and having a layered structure that allowed "plugging-in" other hardware. But I have come to change my mind recently. I am reading the "ARM system developer's guide" (excellent book by the way. I'm reading it because I want to port some C167 code to an ARM9 environment) in which chapter 5 discusses writing efficient C code for an ARM. The point is, and it is fairly demonstrated, that even common, innocent looking C code can either be efficient of very inefficient on an ARM depending on specific choices made, let alone another processor used! So, if we are talking about squeezing every clock cycle out of a microcontroller - I do not believe that portability without ultimately littering the code is possible!
"Do you think that what the help desk did was stupid [...]"
Are you sure that it was the help desk that attacked your build environment? A number of other words comes to my mind...
I would say that the company has a management problem if any changes to the build environment isn't synchronized with a contact person for each and every project that will be (or at least may be) affected.
A vice president would be quite mad if his electronic diary is suddenly off-line or upgraded to a different program without 100% synchronization of all entered information - and 100% compatible with the local copy stored on his laptop.
A mechanic who finds that some of his wrenches has suddenly been replaced with metric instead of inch (or the reverse) size steps would take his heaviest sledge hammer and go find the culprit.
Per, I meant the "IT department" instead of "Help desk", of course.