NTLDR contains a mini-NTFS filesystem driver and mini registry parser. NTLDR reads the registry and determines all of the boot-start device drivers. NTLDR loads those drivers into RAM, then loads the kernel and the HAL.
NTLDR then passes control of the machine to the kernel, along with a pointer to the in-RAM loaded drivers so that the kernel can start those drivers.
Back in the Win95/98 days, the General Protection Fault dialog box gave lots of information... it gave register values and, if I recall correctly, a hex stack trace.
Certainly that dialog had more information. But it's not useful to the end user (although could be very useful to the developer).
In this case, there's not a lot of useful information that the OS can give to the user.
Oh, get real.
This is not an "instead" thing. This is an "in addition to" thing.
MS has changed its focus to security in recent years. There's just tons of older code in there and it's going to take time and resources to review all of that code.
Your take is complete hooey, also.
Neither SoBig nor MSBlaster executed in kernel space.
RPC service is.. hello! a service! It runs in a user mode program. Sobig was an email worm and ran in the user's context.
Your analysis is garbage.
Exactly. The CPU is always executing instructions.
On the NT operating systems, the System Idle process runs when no other thread is in the ready state. The idle thread executes DPCs and checks for keyboard/mouse input and does some other housekeeping duties for the operating system. So and idle processor isn't really truly idle. It's always doing somethign.
On the other hand, some instructions are more expensive than others. Gamers note that their CPU temps go up when they run demanding games. Heavy math uses more transistors than executing other instructions, which does generate more heat.
The fact of the matter is, that if users HAD installed all patches, they WOULD be fine. They wouldn't have been hit by ANY of the recent worms.
And Microsoft isn't teaching people to click on things that say patch. As a matter of fact, emails from Microsoft and Microsoft's website continuously remind people that Microsoft never sends attachments.
Source code is where now?
I checked that page and can't find the source code.
Can you provide any corroborating evidence that this exploit actually exists? If you can't, this is just hearsay.
It doesn't have to match.
The only thing required is that the domain of your Sender: field list your ISP's SMTP server as an authorized sender.
At least that's how I read things.
SPF is far simpler overall.
PGP is a client side solution. SPF is a server side solution.
It's far, far easier for the (knowledgeable) sysadmins to make changes than to teach every email user on the planet how to use PGP.
RPC is hardly useless.
RPC is an interprocess communication mechanism that not only allows distributed client/server apps to run, but allows the client and server apps to be on the same machine.
Many apps depend on the communications that RPC allows.
Actually, Outlook 2003 will allow you to do exactly this. You will have symbolic links just as the original post described. I think of them as SQL 'views' in a SQL Server paradigm.
Actually, when the machine blue screens, savedump.exe checks and sees that there's a memory dump and does indeed offer to report back to Microsoft if configured to do so.
That's just ignorant.
Any device driver running on the system has complete control of the system.
To architect an OS otherwise would take such a huge performance hit to make the OS unusable.
Any device driver can blue screen a Windows machine. It's the nature of the beast. And it is in no way Microsoft's fault if a third party device driver does something that is clearly illegal according to the DDK.
Read the other posts about the same thing being true of Linux kernel modules and PDP systems.
I can't make sense of the quote.
Dr. Watson traps user mode crashes, not operating system crashes.
I can say for absolute certain that I see many more blue screens caused by non-MS code than I do caused by MS code. And I know for a fact because I load up those memory dumps and do analysis on those crash files.
BTW: there is a similar 'feature' that does indeed send blue screen data to MS once your machine is rebooted.
This is very true.
In fact, all FAA regulations aside, I believe there is an FCC regulation that makes it illegal to use a cellphone in a plane for precisely this reason.
Slashdot Mirror
NTLDR does the dirty work.
NTLDR contains a mini-NTFS filesystem driver and mini registry parser. NTLDR reads the registry and determines all of the boot-start device drivers. NTLDR loads those drivers into RAM, then loads the kernel and the HAL.
NTLDR then passes control of the machine to the kernel, along with a pointer to the in-RAM loaded drivers so that the kernel can start those drivers.
Poor code quality is not solely a result of moving to offshore programming.
American programmers can write equally poor code.
Back in the Win95/98 days, the General Protection Fault dialog box gave lots of information... it gave register values and, if I recall correctly, a hex stack trace.
Certainly that dialog had more information. But it's not useful to the end user (although could be very useful to the developer).
In this case, there's not a lot of useful information that the OS can give to the user.
...for me to patent the conditional jump statement?
Oh, get real. This is not an "instead" thing. This is an "in addition to" thing. MS has changed its focus to security in recent years. There's just tons of older code in there and it's going to take time and resources to review all of that code.
I was always told that NT stood for "New Technology." Which might explain why they removed the moniker from Windows 2000...
Your take is complete hooey, also. Neither SoBig nor MSBlaster executed in kernel space. RPC service is.. hello! a service! It runs in a user mode program. Sobig was an email worm and ran in the user's context. Your analysis is garbage.
Exactly. The CPU is always executing instructions. On the NT operating systems, the System Idle process runs when no other thread is in the ready state. The idle thread executes DPCs and checks for keyboard/mouse input and does some other housekeeping duties for the operating system. So and idle processor isn't really truly idle. It's always doing somethign. On the other hand, some instructions are more expensive than others. Gamers note that their CPU temps go up when they run demanding games. Heavy math uses more transistors than executing other instructions, which does generate more heat.
The fact of the matter is, that if users HAD installed all patches, they WOULD be fine. They wouldn't have been hit by ANY of the recent worms. And Microsoft isn't teaching people to click on things that say patch. As a matter of fact, emails from Microsoft and Microsoft's website continuously remind people that Microsoft never sends attachments.
Source code is where now? I checked that page and can't find the source code. Can you provide any corroborating evidence that this exploit actually exists? If you can't, this is just hearsay.
That would be no different than the recent IBM DeathStar drives, now would it?
It doesn't have to match. The only thing required is that the domain of your Sender: field list your ISP's SMTP server as an authorized sender. At least that's how I read things.
SPF is far simpler overall. PGP is a client side solution. SPF is a server side solution. It's far, far easier for the (knowledgeable) sysadmins to make changes than to teach every email user on the planet how to use PGP.
Only if you call it a Dewey Decimal System organization, apparently. If you call it the Hinkkanen System, you're fine. :)
RPC is hardly useless. RPC is an interprocess communication mechanism that not only allows distributed client/server apps to run, but allows the client and server apps to be on the same machine. Many apps depend on the communications that RPC allows.
Actually, Outlook 2003 will allow you to do exactly this. You will have symbolic links just as the original post described. I think of them as SQL 'views' in a SQL Server paradigm.
Actually, when the machine blue screens, savedump.exe checks and sees that there's a memory dump and does indeed offer to report back to Microsoft if configured to do so.
That's just ignorant. Any device driver running on the system has complete control of the system. To architect an OS otherwise would take such a huge performance hit to make the OS unusable. Any device driver can blue screen a Windows machine. It's the nature of the beast. And it is in no way Microsoft's fault if a third party device driver does something that is clearly illegal according to the DDK. Read the other posts about the same thing being true of Linux kernel modules and PDP systems.
I can't make sense of the quote. Dr. Watson traps user mode crashes, not operating system crashes. I can say for absolute certain that I see many more blue screens caused by non-MS code than I do caused by MS code. And I know for a fact because I load up those memory dumps and do analysis on those crash files. BTW: there is a similar 'feature' that does indeed send blue screen data to MS once your machine is rebooted.
This is very true. In fact, all FAA regulations aside, I believe there is an FCC regulation that makes it illegal to use a cellphone in a plane for precisely this reason.