Hacker News Reader

Comment by derefr | Hacker News Reader

I believe Microsoft's internal build toolchain was part of the leak. Looks like the particular tool used wasn't part of the centralized CI system, but rather one intended to be used to time how long builds take (guessing: intended to be run on the developer's workstation as a pre-checkin checklist step, in order to avoid committing code that bloats CI build-time?)

View on HN

Heh, nope, `timebuild.pl` is the canonical entrypoint for an "official" Windows build, and has been for a very long time. It's a hideously elaborate dependency resolver and task runner that is responsible for tying together all the various build steps necessary to create an installable OS.

refs: https://web.itu.edu.tr/~dalyanda/mssecrets/other/Startup.htm

  In order to perform these operations, execute the following command from within a razzle window, whose current directory is %sdxroot%.
  ·         perl tools\timebuild.pl

https://careers.microsoft.com/us/en/job/869511

  Experience with “Timebuild”, razzle, and the Windows build system

That job description is strange to me–how could they ask for experience with an internal tool? Is it just a filtering mechanism to hire ex-Microsoft employees? This seems like an Apple job posting asking for experience with XBS, or an Amazon one asking for Brazil familiarity–unless this has been published in some form to the public, like Google and Facebook have done?

> #gamingjobs

Heh. Someone needs to tell Microsoft recruiting to dial back the "fellow kids" :P

Most large companies, for various legal, policy, and compliance reasons, require job requisitions to be posted externally in order to be posted for internal hiring and vice versa. This job listing is probably intended to make an internal hire.

But why not list it as a "required" qualification then? This way, people will apply because they think it isn't necessary.

People will apply anyway because so many requirements aren't.

Also, people do boomerang to companies they've worked at before.

I've seen companies list x number of requirements and hire someone that doesn't meet any of the "requirements".

Obvious that person had great culture-fit. /s

the company and the hiring manager are interchangeable here and it's a lot easier to make sense of this if you know that it's basically one person making this decision instead of some nondescript black box grinding gears.

Because some middle manager is likely filling out a web form with zero regard for accuracy because it's just a formality they already have someone in mind and HR is gonna bin all the resumes anyway.

If that someone is a guest worker the job posting is legally required.

They do it if there is a candidate(s) internally they want to hire, but HR requires (either because of laws or internal policy) that they also look for outside candidates. The outsiders won't pass the screening because they don't have experience with the required tool, and the team gets to hire the person they wanted anyway.

I wonder if you can still apply if you're managed to sus out the requisite experience through reverse engineering…

Depends, some places only want to count experience if it can be linked to hours you billed.

How would this comply with the law if an external candidate would have no chance to pass anyway (due to work experience required with an internal tool not available to the public)?

Wouldn't posting a job that an external candidate has no chance of obtaining still violate the intent of that law?

There can be external candidates with that qualification. In general the standard is “Bona Fide occupational qualification” which means that you have a legitimate reason for the requirement. For a college hire this would likely not suffice ... you can teach a college hire what they need to know. For the engineering director running the project it very well might be.

Incidentally, a bunch of people outside Microsoft had access to these tools (e.g. academics).

The job posting lists it as something preferred but not a hard requirement.

Don’t forget former employees.

That's exactly what it is. I worked at IBM many moons ago, and at one point was asked to create a list of job requirements that would ensure I was provably the only person in the world who met the constraints. Big companies are weird, man.

It's also how procurement works in the public sector. Either of their own, or with a help of an external consultant, public sector workers will create a set of requirements that are tailored to fit a particular desired supplier, with a bunch of extra bullshit requirements thrown in so that technically allows other competitors, and doesn't look obviously illegal.

Once worked with a network guy who always specced out EIGRP as a requirement to ensure he always got Cisco routers.

Suddenly that contracting company asking me to fudge the wording on my work experience is starting to make sense...

Seems perfectly legitimate to me. Returning, former employees, are a thing.

Who outside of Microsoft is going to have experience with the Windows build system?

Is this like recruiters looking for 20 years of Go experience lol?

Lots of people who have never worked for Microsoft have experience building in the Windows codebase.

Large OEM partners that need to do driver development, academics, and government customers are all granted source access licenses.

Which build of Perl is used inside Microsoft? ActiveState? Strawberry?

Probably ActiveState.[1] Microsoft had surprisingly good support for Perl back in the day, and I remember running into knowledge base articles or documentation that had Perl snippets in examples of how to automate some things.

1: https://www.perl.com/pub/1999/06/activestate.html/

Huh. From the referenced memo:

> The complete list of depots follows [...]

> Admin, Base, COM, Drivers, DS, EndUser, InetCore, InetSrv, MultiMedia, Net, PrintScan, Root, SdkTools, Shell, TermSrv, Windows

...which bears a striking resemblance — both back then and to this day — with the root-level categories that divide up the features in the "Add or Remove Windows Features" chooser in the Control Panel.

I guess those root-level categories in the chooser (which were always pretty meaningless) turn out to represent which particular Microsoft source repo the component's code can be found in.

As a wild guess, the "Add or Remove Windows Features" chooser is the way it is, because it's the runtime representation of what's actually mostly a build-time feature selection system; where disabling a component at build time speeds up your build, at the cost of that component being forcibly greyed out in the "Add or Remove Windows Features" chooser for that build. Basically the same as disabling the building of a kernel module in a Linux modular build.

As Raymond Chen would say, "it makes sense with kernel-tinted glasses."

Er, a few problems with the reasoning here:

1. Windows developers did not build large parts of the product on any regular basis. Windows took ~18 hours to build on incredibly powerful build lab hardware -- as soon as it took longer, it was time to buy a new build lab. Incremental rebuilds were notoriously flaky, at least in the days before https://github.com/microsoft/BuildXL. The most common dev loop that I saw was to install a recent dogfood build (so APIs and binary interfaces were reasonably recent) and then repeatedly rebuild and clobber binaries on that install.

2. The only real build-configuration options for timebuild were architecture and compile mode (dbg, chk, fre, opt). There wasn't an option to build or not build parts of the tree.

3. raymondc's reference to "kernel-colored glasses" is about viewing things from the kernel side of API guarantees. This is more an applied lesson in Conway's Law.

Re: the second point, I wasn't hypothesizing passing a runtime option to timebuild, but rather running a build against a local "root enlistment directory" that has the Base and Windows depots synced, but not necessarily all the depots for the other components.

I suppose this wouldn't have resulted in an installable release, though. (At least on its own. I guess the populatefromvbl.pl script described in the memo is there to bodge a partial clean build of individual components, together with "the rest of Windows" from some parent release, to form a test build?)

oh god, flashbacks. when I joined Azure Fabric we'd inherited Razzle and all its arcane passes. I still have no idea why; we weren't part of Windows except in name back then.

also, what a strange email to be public. not that it's a hot secret, but who cares about sdx outside of MS 10 years ago?

I've said for a long time that if you could snap your fingers and delete all Perl code in the world the lights would turn off. I didn't realize Windows builds would also cease.

I thought that by the time Windows XP was under development Microsoft had migrated to Perforce and individual dev teams were running their own full Windows builds.

Reply on news.ycombinator.com