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.
Why not recommended? As far as things close to signals go, this is how you implement signals in user land on Windows (along with pause/resume thread). You can even take locks later during the process, as long as you also took them before sending the signal (same exact restrictions as fork actually, but unfortunately atfork hooks are not accessible and often full of fork-unsafe data race and deadlock implementation bugs themselves in my experience with all the popular libc)
I’ve implemented them as you describe, but it’s still a bit hacky due to lots of corner cases — what if your target thread is currently executing in the kernel?
The special APC is nicer because the OS is then aware of what you’re doing— it will perform the user-mode stack changes while transitioning back to user-mode and handle cleanup once the APC queue is drained.
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 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.
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.
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.
That's correct. On NT/Alpha context switching was done in ntos\ke\alpha\ctxsw.s, which was regular kernel mode assembler code. A PAL call was made but it simply set the new Teb and Pdr; two or three lines of code. I've never seen the PALcode for VMS or OSF/Tru64 but the NT PAL for swpctx was designed so that alpha assembler code in NT looked as much like the mips code that davec wrote. It made the port easier that way.
Interesting Raymond continues to mention NT/Alpha now and then. If you run into him mention I have a collection of NT/Alpha artifacts and anecdotes he might be interested in.
I believe in the specific case of L4/Alpha, the PALCode did perform the context switches. Granted, I doubt it was as robust as the VMS or Tru64 PALCode versions that were production-ready.
PALcode implemented context switches for all systems, including Linux (which uses Digital Unix PALcode). Specifically, PALcode covered various internal details of the CPU presenting unified interface to OS - each CPU needed custom PALcode implementation, though IIRC there were only few mandatory PALcode calls (related to memory barriers, iirc). The kernel covered switching OS-specific structure pointers over, PALcode handled all sorts of MMU, TLB, PASID indexing of TLB, internal CPU state etc.
L4/Alpha PALcode was limited to specific set of CPUs it was implemented for, so unlike VMS, NT or Digital Unix PALcode it wasn't available outside of those few machines.
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.
Disclaimer: I worked at MSFT for 14 years, but that was >10 years ago, in Servers (Exchange, ISS) not kernel. But I've debugged windows stresslab crashes across the network, before windbg got good :)
Is it difficult to transition? Yes, in that if you spend 10 years learning SystemA, then it will take some time with SystemB to build up to the _same level of expertise_ that you enjoyed on SystemA.
The neat thing about learning one OS or system _deeply_ is that the deep knowledge gifts you with frameworks for learning the next-system.
I wrote software on various *nix'es during my university time, then worked on OS/2 (yes, "OS-who?"), Windows, and now I'm at Google, (my work involves 80% Linux 20% Win). It took me some time to re-build my skills on each environment/platform, but it's been a great ride and a lot of fun.
(P.S. earhart@ pointed me to this thread, and says hi to all y'all: Evan, JonO, JVert, LandyW? Dan?)
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.
