jvert

Long, long, (long) ago I used to teach people to juggle at the local Renaissance Fair. I would say I could get almost everyone to flash 3 in less than 30 minutes. Most people walked away having at least 5-6 successful throws. The only people who really couldn't learn are those who don't like to fail and won't even try. Learning to juggle is repeated failure and you have to be willing to persist. Learning 5 clubs (very briefly) took me many years of repeated failure.

Early in Win32 development, the x86 calling convention was __cdecl. I did all the work to change it to __stdcall (callee clean-up). Yes, it was done purely for performance reasons. It was a huge change to the codebase and as a side-effect turned up a lot of "interesting" code which relied on cdecl calling conventions.

Or SetThreadContext() if you want to be hardcore. (not recommended)

Windows NT did this too. And it was the work of one engineer. (although that engineer was Dave Cutler…)

NTFS was definitely a new filesystem and supported many capabilities not in HPFS. Windows NT also shipped with HPFS support which was a complete reimplementation of the HPFS filesystem which shipped with OS/2.

This is a bit of a game of telephone - NT Alpha shipped after NT 3.1 (i386 & Mips) and the port was done almost entirely by DEC. The blue screen preceded the Alpha and was really based on the color scheme from the firmware on the Mips workstation which Microsoft built internally. And, of course, the legendary SlickEdit, which was one of the original editors available on Win32.

After NT 3.1, Microsoft assumed primary responsibility for NT Alpha, although there were also some great people at DECWest still involved.

source: me, I'm the 'someone _else_' who owned all the Alpha stuff at Microsoft.

Groopit | Sr. Software Engineer | Fulltime 100% Remote (US) | $120K, benefits, equity | Seattle, WA | https://www.groopit.co/

Groopit is a rapidly growing enterprise SaaS business and we’re seeking a fast learning, motivated Software Engineer with an entrepreneurial spirit and positive attitude to jump in and join our team. We're a small team (two engineers) with deep industry experience and we will be expanding quickly.

You should be comfortable working across backend, frontend, and mobile client stacks to build high-quality software.

Our tech stack is ASP.NET Core (C#), SQL Server, Azure, Typescript and React, Kotlin (Android) and Swift (iOS)

We offer competitive salary, benefits and equity.

Familiarity with SAAS applications and integration with enterprise platforms such as Salesforce, Microsoft 365, or Okta is a plus. - BS degree in Computer Science or related field. - 3+ years' experience as a Software Engineer. Familiarity with software engineering tools, methodology and release processes. - Experience developing and deploying SAAS applications to enterprise customers.

https://www.groopit.co/jobs to apply.

Groopit | Sr. Software Engineer | Fulltime 100% Remote (US) | Seattle, WA | https://www.groopit.co/

Groopit is a rapidly growing enterprise SaaS business and we’re seeking a fast learning, motivated Software Engineer with an entrepreneurial spirit and positive attitude to jump in and join our team. We're a small team (two engineers) with deep industry experience and we will be expanding quickly.

You should be comfortable working across backend, frontend, and mobile client stacks to build high-quality software.

Our tech stack is ASP.NET Core (C#), SQL Server, Azure, Typescript and React, Kotlin (Android) and Swift (iOS)

We offer competitive salary, benefits and equity.

Familiarity with SAAS applications and integration with enterprise platforms such as Salesforce, Microsoft 365, or Okta is a plus. - BS degree in Computer Science or related field. - 3+ years' experience as a Software Engineer. Familiarity with software engineering tools, methodology and release processes. - Experience developing and deploying SAAS applications to enterprise customers.

https://www.groopit.co/jobs to apply.

PAL code didn't do anything like context switches and I'm not sure how it could, given how the OS needs to know the specifics of the thread context in many scenarios.

I like to learn new things; I find it energizing, especially when I am feeling burned out. Sure, it can be difficult but that is also what makes it rewarding. It's also really interesting to see the different tradeoffs that have been made between different solutions. (Linux vs Windows for example)

Ultimately, it's all just code and problem solving. And you can usually find a way to leverage your expertise in one domain into a different domain.

I spent about ten years on the Windows Kernel team. In the 90's, so likely very different than what you would experience today, but probably still a lot of the same problems. (Funny to hear people are still complaining about windbg!)

I think you are coming at this from the wrong perspective. Rather than thinking about how to avoid work you DON'T like, think about what you DO like and then decide if the new job would offer more or less of that.

Personally, I've found that every five years I end up sick of working on the same kind of problem and I have to go work on something completely different. Maybe that's where you're at.

In Win32, this handle is called the AccessToken https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... and the calling thread's current access token is used by OpenFile to grant or deny the requested access.

Cutler Normal Form has open braces at the end of the line, so it should be

    if (argc == 2) {
   
        //
        // explanatory comment
        //
    }

Also, Dave hates Hungarian notation of any flavor.

Raymond is almost always 100% right, but in this case he (or Adrian) is a bit off. The mini filesystems in NTLDR can absolutely traverse subdirectories. After all, things like the kernel are found in places like C:\WINDOWS\SYSTEM32\NTOSKRNL.EXE and NTLDR has to load that. There is a "nanofilesystem" in the boot sector(s) which only knows how to load C:\NTLDR, but NTLDR could easily restore a hibernation file that was in a subdirectory.

The real reason these are in the root is because There Can Be Only One. You can have multiple versions of windows in different directories on the same drive, but only one NTLDR or BOOT.INI or HIBERFIL.SYS. If you put them in subdirectories, then you can now have more than one and NTLDR doesn't know which one to use.

And as somebody else pointed out, this all got rewritten after Windows XP.

email me, johnv at valvesoftware.com, and we can discuss it

I spent 21+ years at Microsoft. From college hire to partner level. Finally got fed up and left for a smaller company 2 years ago. Sure, I'm making less money but I'm working with great people, building cool stuff, and not wasting my time on bureaucracy & management. Don't get hung up on the $$ if that's not what makes you happy.

So Google has a different algorithm for computing the stank rank, but still stack ranks? Microsoft also incorporates peer feedback into the review process, but treats it as just another input into the manager's decision process.

If you manually add the Valve repo at http://repo.steampowered.com then "apt-get steam" will do exactly what you expect. Or you can download the .deb from http://store.steampowered.com and install it.

There are no 64-bit binaries. Steam is a 32-bit program. Frankly, porting it to 64-bits is pretty low on the priority list right now.

Hi everyone, we appreciate the feedback. And we will appreciate it even more if you move it from HN to the Steam Linux Beta forums at http://steamcommunity.com/app/221410/discussions/.

First, I want to correct my typo - we are initially targeting Ubuntu 12.04 LTS (not 10.4 as I fat-fingered above) We are not looking at other distros in this limited beta release but obviously we don't want to do anything to preclude this in the future.

The dropbox and chrome examples are a little different. They ship both 32-bit and 64-bit .debs so they don't hit the multi-arch issues we did. Try to install the 32-bit dropbox .deb on x64 Ubuntu 12.04 and you will see the same problem (python-gtk2:i386 conflicts with python-gtk2)

Hopefully we can get the multiarch issues ironed out with Canonical (a lot of problems have already been fixed in updates). Believe me, I would like nothing better than to remove the gross hacks.

Those things are explicitly added post-install because a package can't have cross-architecture dependencies and not all the 10.4 packages support multiarch. For example, if your 32-bit package depends on xboxdrv, it can't install on an Ubuntu 10.4 x64 system. (ditto for libappindicator1, jockey-common, etc) I don't see how defining our own repository helps this problem at all. (and isn't what dropbox, chrome, etc. do anyway)

Thanks for the feedback though.