jvert
Joined 14 years ago
Karma
108
Submissions
21
Member since
Nov 7
Recent submissions
Comment · 6 months ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
Or SetThreadContext() if you want to be hardcore. (not recommended)
Comment · 1 year ago
Windows NT did this too. And it was the work of one engineer. (although that engineer was Dave Cutler…)
Comment · 2 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 4 years ago
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.
Comment · 4 years ago
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.
Comment · 9 years ago
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.
Comment · 10 years ago
Cutler Normal Form has open braces at the end of the line, so it should be
if (argc == 2) {
//
// explanatory comment
//
}
Comment · 11 years ago
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.
Comment · 12 years ago
email me, johnv at valvesoftware.com, and we can discuss it
Built & shipped my own releases of both Windows and Linux :-)