That's all well and good, but what features exactly were taken away in Vista that were found in XP?
The backup program has been nerfed, for one. I'll summarize what I posted on the Shell: revealed forums (a forum set up by MS late in Vista development to get feedback on the RCs) as of RC2 that Vista Backup (stclt.exe) can't do but ntbackup.exe from previous versions of Windows (which is not included and not compaitble with Vista) could:
You can't actually select the files you want to back up. You have to pick an ambigious category of files or back up the entire hard disk.
You can't backup EFS encrypted files, either in their raw format or unencrypted. NTBackup could archive the encrypted form, for use with seperately archived keys.
It's unclear if it backs up extended attributes, alternate file streams, security descriptors, reparse points, and hardlinks.
It can't back up registry hives, except in a full-system backup.
The scheduling options are much less flexible than before.
You can only include local (not network) files in an archive.
The help is awful: there are at least two different hyperlink-in-dialog style help links that both go to a single generic FAQ that doesn't actually include the linked questions.
You can only back up to DVD or network, or for non-full backups: CD. Nothing else. You can't put the archive on another hard disk. NTBackup let you put the archive anywhere. The question of why you can't use a HD is one of the unanswered question links.
You need admin access to back up your OWN files. Another unanswered question link pretends to offer the rationale for this.
Vista backup doesn't seem to have any command line support. NTBackup had tons.
You are referring to POSIX I presume. Well, have you seen any native Unix code running on Windows lately? I didn't! Windows POSIX compliance is a joke, it was more of a marketing ploy to tell their client ("we even run Unix!") but in reality it is very broken.
Are you referring to only the built-in posix subsystem? If so, I agree that it's a joke. OTOH, Microsoft distributes Services for UNIX, a real UNIX subsystem for NT, not based on Win32.
That is why you have Cygwin...
SFU works much better than Cygwin in a lot of ways, including real COW fork support, no unnecessary overhead from the Win32 subsystem (like excessive process start overhead), and no common read-write shared memory section for all processes (representing an egregious security vulnerability).
He asked for questions and I ask him why NT doesn't have proper vms-esque device names (dka0, etc). The question didn't go down very well. I supose that would break too much stuff.
NT does have device names like \Device\HarddiskVolume1 and \Device\USBPDO-3. Win32, OTOH, hides them all behind the \DosDevices directory, which just contains a lot of object symlinks like \DosDevices\C: -> \Device\HarddiskVolume1. Much of the ugliness that people attribute to NT is actually a part of the Win32 layer, not the underlying system.
I can't imagine them working on GPL'd stuff and having to release the code.
The GPL allows linking to non-GPL operating system libraries, which lets them avoid releasing OS code. Microsoft distributes lots of GNU GPL'd stuff with Services for UNIX, a POSIXy environment subsystem built directly on NT, alongside Win32.
Firstly, you can't use normal "commands" to create/delete NTFS symlinks. The collection of system calls to create a symlink are badly documented and incomplete.
There are no dedicated syscalls for manipulating reparse points. To create a reparse point, you create an empty file or directory and then use the FSCTL_SET_REPARSE_POINT with the NtFsControlFile syscall (possibly via the DeviceIoControl Win32 function). To open an existing reparse point, specify FILE_FLAG_OPEN_REPARSE_POINT during a normal open operation, use FSCTL_SET_REPARSE_POINT to get its properties and FSCTL_DELETE_REPARSE_POINT to make it not a reparse point anymore. All of these operations are documented.
As for tools, the Windows resource kits have linkd.exe, mountvol.exe, and delrp.exe (mountvol is standard since XP), and Sysinternals has junction.exe. Junction comes with source code. However, there is no GUI for reparse points, and as you pointed out, lots of apps are not prepared to deal with them.
No, ozzee knows exactly what he's talking about. NT 5 suppports filesystem "reparse points" which are closer to symlinks than hardlinks because they contain a pointer to the target file in the form of its filename.
When you try to open a file (or directory; just a special type of file), the filesystem checks to see if the file (or any of its path elements) is a reparse point. If so, the filename you're searching for is replaced with the target of the reparse point (a new filename), and the kernel starts a search for this new filename from scratch. If the open succeeds, the file you have open is the one targeted by the reparse point; the fact that it was opened via a reparse point is forgotten. It's the same as if you had specified the reparse target in the first place.
Let's say that you have two disk volumes: C: and D: which Win32 has pointing to \Device\HarddiskVolume1 and \Device\HarddiskVolume2. A program tries to open C:\rp\f.txt. Win32 converts this to \Device\HarddiskVolume1\rp\f.txt
The IO manager creates a file object F named \Device\HarddiskVolume1\rp\f.txt and asks the the filesystem mounted at \Device\HarddiskVolume1 to find it. The filesystem realizes that \rp is a reparse point to \Device\HarddiskVolume2\dir.
The filesystem replaces F's name with \Device\HarddiskVolume2\dir\f.txt and returns F to the IO manager. The IO manager starts the file search over again, this time asking \Device\HarddiskVolume2 to open \Device\HarddiskVolume2\dir\f.txt. \Device\HarddiskVolume2 finds \dir\f.txt and the open operation succeeds. As far as anyone knows, the program had asked to open \Device\HarddiskVolume2\dir\f.txt directly, because that is the name now associated with F. If the program wants to delete/rename the file, it's now referring to D:\dir\f.txt, not C:\rp\f.txt. If the program had really intended to open the reparse point itself, it had to specify FILE_FLAG_OPEN_REPARSE_POINT during the open operation. The Win32 DeleteFile() and MoveFile() (for rename) functions do not specify this flag, and so affect only the target of a reparse point.
In all the versions of Windows I know of, NTFS will only let you create directory reparse points, and the target must be to a local volume (not network). AFAICT, there are no technical reasons for these restrictions. I think a lot of the concerns are about how many apps would be incompatible with full symlinks. At some point, I'm planning to write a kernel driver to try and bypass this check. Even if I couldn't get NTFS to use non-direcory, arbitrary target symlinks, a filesystem filter could intercept the open requests and enact reparsement itself.
However, many sites I run across have MS Windows admins that tell their users that such practices don't work with non-MS apps. If it were just one or two, I'd blame the third party vendor, but from where I stand MSI seems to have some impediments.
I have rarely seen a broken MSI package (one notable exception is recent HP printer drivers+software, plus a lot of other problems), but we can both argue until we're blue in the face about incidence without any real data. But how about this: if a software developer can't be bothered to implement the install system correctly on Windows, what makes you think they are going to do it correctly on other platforms? Can you point to any specific reasons why Windows Installer is inferior to a modern UNIXy package management system?
The fact that it's been out for so many years, yet still not widely utilized suggest some deficiencies or defects which prevent its use in practice. Either that or MS only shops are flat out lying when they tell users that other software can't be remotely installed. It's a message spouted at far to many sites for it to be an anomaly.
Maybe some vendors haven't switched because they've always done it in some other way, don't care about being compatible with the OS, don't care about remote installation and can't be bothered to put forth the effort to fix it? Popular software is often Good Enough* (*for a narrow set of predetirmined user requirements). This isn't magically going to change if the platform is a UNIX.
One nice thing about Linux distros is that they have a lot of control over which software packages are accepted into their repositories (including necessary modifications), and those repositories tend to be quite large. Trying to pick up a piece of software NOT in the distro repository can be quite a pain, though.
Microsoft doesn't have nearly the same control over the software people sell for Windows. They do have a "Designed for Windows" logo system with a set of requirements (including unattended installation and LUA support), but they can't force companies to comply (if they made any effort to make them comply or require proper use of Windows Installer, people would cry monopoly; Linux distro repositories can make any requirements they want). How many apps that have that logo also have problems installing remotely?
I will say that UNIX software has a higher baseline quality than Windows software does, if only because UNIX users tend to be pickier than Windows users. This is not to say that both platforms don't have their share of high and low quality apps.
If you're doing that, then with only two or three extra steps, you can roll it into a local package which can then be handled automatically by the package manager such as APT or RPM.
Sure, and you can sometimes create.MSI packages out of other installers if the installation is straight-foward enough. Even if you conduct the installation normally on one computer and then transplant the installed files and keys to other machines via a MSI package.
Removing admin access for the users helps a bit, but most spyware, rootkits, and other malware roll right in through MSIE or MS Outlook.
IE, OE, Outlook, etc. are not paths of privilege escilation. They run with exactly the same privileges that they're started with; i.e. the logged on user's. Rootkits definately need admin access to install. Almost all spyware, viruses and misc. malware require admin access to work (even if they could theoretically be functional with less). Try it some time: try to get a Windows machine infected with anything you can, given only standard user privileges. Besides, IE, OE and company are a lot more secure than they once were, and there exist alternatives that can be used.
Unlike Red Hat's kick start or Debian's APT, the third party apps have to wait until they can be installed manually.
Not if the app develper uses the Windows Installer properly. MSI packages support unattended installation (with any install options selected ahead of time), and can be made an automatic part of an unattended installation of Windows, or automatically pushed to computers or users attached to a domain via group policy at any time. Windows installer has been the only supported method of installation since Windows 2000, and the installer runtime has been redistributable to older versions since at least MS Office 2000.
If you're complaining about 3rd party installers that don't use Windows Installer, they are not supported in the OS design, and it's hardly the OS's fault for their existence. It's not like UNIX platforms don't have programs that use non APT style installers that are fragile and need heavy modification and babysitting to work correctly.
The "re-format and re-install" mantra has the effect of reducing competition because of the difficulty in auto-installing third-party software on MS-Windows.
It's a bad mantra. If you follow some basic security rules on your network (#1: users don't get local admin for normal login), Windows is no more prone to malware than any other OS. If the app has a problem with these basic limits, the app is designed wrong (and not supported in the OS design (or any mutliuser OS design)). You wouldn't tolerate a user program that requires root on UNIX; don't tolerate apps that do the same on Windows. If an app can be easily ported to a UNIX, it is already following LUA (be it on a Windows or UNIXy host).
I don't get malware on Windows. I don't depend on anti-malware software, either. With a few precautions, my users don't get malware either. If they are, you're doing it wrong.
It is NOW about NAFTA shipping jobs out of the country to the benefit of a few owners.
Are you sure it's only for the benefit of a few people? The people RECIEVING the jobs are certainly benefiting. With more jobs, and increased income lots of good things happen. You can't industraliaze but very slowly without industrial jobs from an outside source. The more outsourcing that's done, the faster the rest of the world can industrialize. I'd argue that an industrialized nation is far better for its people (and all people, really) than any of the more primitive alternatives. Globally, it's zero-sum at worst.
As for the country losing the jobs, it's painful for the people that were unrealisticly hoping that things would never change-- hoping that they would never have to learn more high level skills. The transition can be hard, but what change isn't? I'd argue that a country with many higher-skilled and workers is better than one with many low skill production workers (the primary type of job outsourced). We should be trying to increase the skill levels of our workers, and this means moving the lower skill jobs elsewhere. I know I don't want to do a repetitive, low skill production job. I want the total economic benefits that come from cheaper unskilled labor.
It is about hiring illegals to avoid taxes - again so owners can profit AND avoid paying taxes.
That's a problem, but it's a tax regulation problem, not a market problem. I think we should look into making second-class class citizenship official (with much lower taxation and tax funded benefits). Illegal immigrants exist and perform a real funciton, even if the state would like to be in denial. There exist many jobs that can only be done profitibly without the artifical constraints of minimum wage and extensive social benefits. Illegal immigrants fill this role. If you want to extract taxes from this, the first step is to legalize it.
It is about making copyright terms last centuries, thus depriving society of any real benefit of an invention.
Copyright is a government-enforced monopoly, contrary to a free market. This is an issue of state interests being corrupted by special interests. More socialization will only increase the opportunity for such corrution. And "depriving society of any real benefit of an invention"? Come on. Don't tell me that you don't derive any benefit from any of the pervasive copyrighted and patented things.
It is about academic researchers doing research with gov money and then personally patenting discoveries tax payers paid for in order to charge exhorbant "license" fees.
I am not familiar with this effect. In any case, this seems to stem from government tax funding (which is not a source of funding in a free market). It sounds like federal funds are being dispensed without requiring the researchers to release findings. This is the fault of whomever in the government is releasing the funds with lax requirements. The fact that such a gaping hole is being exploited is hardly suprising. Perhaps this is another case of special interest corruption?
It is about health insurance companies "coordinating" benefits so that the gov pays first and they pick up the difference, but still collect the FULL premium.
In a purely free market, the government wouldn't be covering ANY medical expenses for the insurance companies to depend on. Besides, aren't all the insurance compaines up front about what things they cover, what things the state covers and how much you'll be paying? Why would you, as a consumer, want to buy insurance on something that the state covers anyway? If the insurance company offered two packages, equal except that one overlaps with what the state covers (and costs more for it) and one that doesn't overlap (and so costs less) which would you pick?
It is about EULA's, DRMs, and other unholy contracts that remove freedoms which the
That depends on if I control the NAT router that has the real address. If so, I can and have on many occations forwarded TCP port 3389 (Windows remote deskop), TCP port 23 for SSH (with optional tunneling of 3389 over that) or OpenVPN on 1194 from either/both ends (from one end, even if I only control one public IP). It can be ugly, but the implicit non-public routability of my private network is good for security.
Yeah, they allow those useless tags but block some of the more meaningful (but anti slashdot revenue) tags like "slashvertisement" (for example); there really are some articles that are little more than product ads. If the tag was applied consistently and I had the option to hide those stories, I'd consider using it. Anyways, since they've already started the precedent of blocking certain tags, it'd make sense to add these useless ones to the list.
I think the only way to fix it would be to have a meta-tag system like the post moderation system. At least then, it would take a conspiracy of randomly selected users to get bad tags attached.
PatchGuard is about stopping modifications to the kernel's internal structures, like the syscall table and the kernel's image. It has nothing to do with loading drivers that use only the kernel's public interfaces.
However, Microsoft HAS decided that only kernel-mode drivers signed with a SPC (software publishing certificate) can be loaded on x64. Microsoft doesn't charge anything for a SPC directly, but you do need to buy a cert from a commercial CA like Verisign. There is also an option that the user can specify during boot-up to disable the signature checks.
I, too, am worried about how inconvenient or expensive it will become to use free/open source drivers in Vista like Daemon Tools and OpenVPN. Although since I reboot so infrequently, I can live with setting the "Disable driver signature enforcement" every time I restart the OS. It's annoying, but usable. The thing is, disabling digital signature enforcement probably breaks all 'protected content' apps... I'm not sure if that's a bad thing or not.
Let's see here: Excel 5.0 was released in 1993 for Win16 and uses undocumented messages in one of the windows common controls. I was hoping for something a little more substantive, more recent, and involving the kernel.
In the InquireVisRgn comment doesn't mention anywhere that InquireVisRgn or the "private entry point" is used by anything but the OS itself. It's not an issue if the OS is using its own private interfaces.
Notice that in the article, they noted that there were about as many compatibility hacks for 3rd party software as there is for Microsoft software. 3rd party apps even got to have the behavior of undocumented functions modified for their benefit at times. Really, Microsoft shouldn't be obligated to keep 3rd party software that does bad things or uses internal functions working correctly (Apple certainly doesn't) but decided to bend over backwards for 3rd party apps in many cases. PatchGuard is all about Microsoft being able to change the kernel's internals without having to worry about breaking 3rd party apps that shouldn't be in there in the first place.
Since MS is closed source, it would be very difficult to produce numerous examples of such private entry points and undocumented interfaces.
That's true, but it doesn't relieve you from the burden of proof. Besides, when the nearly the entire NT4 source was leaked no one cried foul about all the undocumented functions offered to MS applications. I think they would have, if they could have.
So please dont come back with, this source file doe s this this and this which has nothing to do with kernel mode disk access.
The only way to do IO from user mode is through one of the IO syscalls (NtReadFile, NtWriteFile, Nt[Fs|Device]IoControl, Nt[Query|Set]InformationFile, NtQueryDirectoryFile, Nt[Open|Create]File) plus memory mapped files (the Nt*Section syscalls). These functions are in fact part of the kernel's public, documented interface. If the code in question never reaches these syscalls, it's not doing any IO (unless you can show that there's some other way to perfom IO). Basic code traps can show exactly when these calls are being made.
This isn't a security hole. The fact that a process with admin privileges (yes, they're required for this) on the system can modify the kernel is something that can't be fixed by any means, on any OS (except via full TCPA). Microsoft knows that. Trying to protect the computer from malware/viruses that already have admin privileges is a joke. This is designed to make it such a pain for 3rd parties to continue modifying the kernel's internals (something that they shouldn't be doing in the first place) that they switch over to the public interfaces designed for the same purpose. Norton's crying that they have to clean up their code. Sophos already switched over.
What could you possibly be talking about? Direct disk access means bypassing the filesystem and reading and writing to the sectors directly. This requires administrator privileges for good reason: it bypasses file security, file locks and all the other nice things that filesystems do. No user application requires the ability to bypass the filesystem. Don't you need to be root to access a mounted block device on a UNIX? It's the same thing. The fact that it's possible to modify the kernel when you have admin privileges (and physical access for that matter) is hardly suprising, and in fact is unfixable (short of full TCPA).
PatchGuard is only there to discourage apps that hook the syscall table (an inherantly unsafe operation) and make other modifications to the kernel's private, volaitle internal interfaces. When Windows NT was written, the MS devs never expected 3rd party devs to go poking around with the kernel's private interfaces, and are rightly disgusted when those 3rd party software programs cause problems because of it. Compare this to Linux: you are free to maintain your own custom build of the kernel, but in the mainline, all the kernel interfaces are so volaitle, every minor revision is binary incompatible with the rest. You'd never get a device driver accepted into the mainline if it depended on private interfaces that break every revision, even on a source level. Microsoft is well within their prerogative to make changes the Windows kernel's internal, private interfaces. This doesn't work too well when 3rd party apps are dependent on them never changing, especially when Windows crashes because of it. PatchGuard is a technical speed bump to make it harder for 3rd party software companies to screw with the kernel's internals. Microsoft knows that it's an unwinnable arms race, but hope that the 3rd parties will decide it's just easier to stick to the kernel's public interfaces. Microsoft is willing to create new stable public interfaces to support the necessary behavior.
The only thing I can think of that you might be talking about for reduced performance is if you meant no intermediate buffering when you said "direct disk write". The FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH buffering options are unrelated to direct disk access (which actually means bypassing the filesystem to access the block device directly). Write through and unbuffered IO aren't going anywhere.
As for special hooks that MS applications get into the OS that no one else gets, how about an actual example?
Have you seen Clock in a Linux Guest Runs More Slowly or Quickly Than Real Time? It can happen when the 2.6 kernel requests more interrupts for the purposes of clock updates than the host can provide, especially if the host is Windows. The kernel will try to compensate for lost ticks, but this doesn't always work correctly. The main solution is to set the clock interrupt rate back to 100Hz like it was in the 2.4 series (requiring a kernel recompile).
NT 3.1: 3 service packs NT 3.5: 3 service packs NT 3.51: 5 service packs NT 4.0: 6 service packs NT 5.0 (2000): 4 service packs NT 5.1 (XP): 2 SPs so far NT 5.2 (2003): 1 SP so far
Microsoft has never released a service pack once a product reaches the extended support phase, and they usually stall once the deadline is near.
Although they aren't service packs, Win95 had 2.5 OSRs (not upgradable AFAIK), 98 had 2 Editions, and ME had only one release.
So I guess the SP count peaked with NT4 and troughed with XP and 2003. Maybe the count will start going back up now with 3-4 service packs for Vista?
The driver model isn't THAT different; it's not hard to write drivers that are source-compatible with both the 64 and 32 bit archs with only a tiny amount of conditional compilation. Drivers that used to patch the syscall table and can't now in x64 should never have been doing it in the first place. All the Vista flavors (and I agree that there are about 6 too many) use the exactly the same kernel and drivers.
Windows NT didn't use this model in recent releases (it might have done in the 3.5 days; I can't remember)
It never did, and there were never plans to. NT 3.5 was written in C (minus the HAL and a few parts of the kernel, which are assembly), and was source-compatible with Alpha and MIPS, neither of which support more than two privilege modes. Cutler wouldn't let the kernel become non-portable enough to depend on multiple CPU privilege levels. The kernel is designed such that any kernel mode code can dereference pointers anywhere in the kernel's address space (at PASSIVE_LEVEL anyway), and the current thread's user address space (if any). Drivers often operate in the calling thread's context (from user mode), an arbitrary context or in a system worker thread. Most data is stored in the kernel's heaps, and when an object is created, there's no telling which drivers may need to access it in the future. It'd be quite a lot of work to marshall those arbitrary pointers across driver-segment boundries. Apparently, the current kernel designers thought it'd about as much work as just running the drivers in user mode, hence the new User Mode Driver Framework.
The main reasons they aren't implementing the same thing in 32-bit Windows is because of "limitations of the 32-bit architecture" that apparently don't let them do what they want, and since a lot of programs already patch the syscall table in 32-bit windows, it'd break compatibility with a lot of software to change it now. Binary compatibility for drivers that patch the syscall table on 64-bit Windows isn't an issue because 64-bit Windows for AMD64 has always prevented syscall patching. They figure that the 32->64 bit change is big enough to pile on some more changes, like this.
This has more to do with system stability than it does for security. Many syscall interceptors are not multiproc safe or do bad things: if the computer bluescreens because of a poorly written syscall interceptor, Microsoft gets blamed for writing unstable software. The syscall interface is considered an internal interface, not to be tampered with by outside parties because its behavior has subtleties not documented, and could change. This is a technical enforcement of that policy.
I'm not talking about the kernel in particular, although its design is an important part. I think I'm talking about the same thing you are: things like the conventions, the basic abstractions and how they're presented, across all the OS's core components. For example, most kinds of IO are inherently asynchronous: NT and UNIX implement async IO quite differently, yet both provide a similar synchronous interface to IO (with an emphasis on caching to achieve reasonable performance) because that's the way most apps process data. IMO, NT's async IO abstraction is much better than UNIX's.
For that matter, the file abstraction is something that both UNIX and NT use for many of the same things, namely disk files (local and remote), pipes, sockets, and devices. On the other hand, NT doesn't use files to present process information: since by convention everything is an object on NT (a superset of the UNIX "everything is a file" convention, since files are also considered objects-- along with many things UNIX doesn't consider files, like mutexes), you just query the properties you want from a process object. Object property interface vs filesystem interface.
"It's Unix!: You've got a very, very nice GUI but under the hood is good ole' Unix" [emphasis mine]
This I don't understand. UNIX is not the pinnacle of operating system design. Sure, it's very popular, old and diverse across its many incarnations, but it's not the end all be all of OSes. Unlike what Apple marketing says, the best reason for Apple to have chosen a UNIX style design for OSX is because of all the existing software for the platform, including free/open implementations of the platform core itself (i.e. Darwin). Over UNIX's history, security and stability haven't exactly been its biggest features (UNIX didn't have any security in its first versions). Hackability, yes. A strong and diverse community, yes.
Before you say, "Well, at least it's better than Windows!" the part of modern Windows that compares to OSX's Darwin core is the NT core. Both platforms have the majority of their software above the core level, but my question isn't about that. I want to know why popular opinion seems to hold that simply being UNIX = good and great while anything else is implicitly lesser.
I'd put the NT core's VMS inspired design (or VMS itself) up against the UNIX System V or BSD designs any day. For that matter, I'd put their modern implementations up against one another too (NT 5.2 kernel and system (of WS2003), OpenVMS 8.3 and Linux 2.6, OpenDarwin 7.2, OpenBSD 3.9, etc.). I'm sure that there are other OS designs out there worthy of comparison, too. I'm just disappointed by the UNIX = The One True OS rhetoric.
Its interesting that a lot of "high-level" CMS's all implement their own ACL system, but for users/groups as well as content (files). For all the interesting and directly-usefull-to-users apps Novell is building (e.g. Beagle) I've been thinking that it would do them good to build some libraries and proof-of-concept apps that leverage (sory) their excelent low level capabilities. Its just that most developers dont know any better..
I'm afraid that all the major operating systems have many developers guilty of using the OS's low level facilites either incorrectly or reinventing them, especially when it comes to access control.
Windows NT's security model is quite powerful and reusable but almost all devs (Microsoft's own included) misuse or ignore it, and we all know how well that's working out...
Application configuration often has settings that can be applied in a mandatory or default fasion for all users or be customized by individual users depending on system configuration. The most obvious way to have the same settings tied both system and/or user configuration is to give them the same structure where the functionality overlaps. For example, ~/.ssh/config and/etc/ssh/ssh_config: the files have the same structure for both user and and system defaults. In the registry they'd be HKCU\Software\SSH and HKLM\Software\SSH. The fact that user specific and user agnostic config follow the exact same naming conventions and have more overlap on Windows than normally on a UNIX (different distros) is a good thing IMHO.
I don't think I've ever become confused as to if I was in a user's or the system's software key. The old regedt32 uses seperate windows with the Win32 root key in the title bar and regedit shows the current path in the status bar. I tried deleting a key in regedit and it asked "Are you sure you want to delete this key and all of its subkeys?". Regedt32 asks "Registry Editor will delete the currently selected key and all of its subkeys. Do you want to continue the operation?" They both have similar warnings before deleting a value. I'm not sure why you aren't seeing these warnings... I didn't think there was any way to turn them off.
It doesn't take THAT long to boot a PE CD. Much of the time is spent loading drivers for obscure SCSI controllers that you don't have, and that behavior can be avoided. There exist some alternatives to Microsoft's registry editor (all of the required APIs are public); it's just that the built in editor exposes all the needed functionality, and it isn't used often enough to need extra features like the high level text editors have. The only reason you need a GUI to edit the registry is that no one has written a text mode registry editor, or for that matter one that doesn't depend on Win32 (if you depend on Win32, you may as well use its GUI).
IDK if I mentioned it in this thread, but you can back up/restore user profiles with ntbackup, and backup specific registry keys with reg save and restore with reg restore. Regedit also provides save/restore functions in the file menu. It doesn't matter if the profile is in use-- in fact, it HAS to be loaded for reg save/restore. Ntbackup will automatcially detect if the profile is loaded or not. When a user logs off, all references to the profile are supposed to close, but sometimes poorly written services won't cooperate. You may see event log messages about how a user's profile couldn't be unloaded right away because of this.
Registry hives are opened by the kernel; the file handles are in the SYSTEM pseudoprocess. Don't forcibly close them or you're likely to cause a bugcheck. You can try to find registry key handles in user processes to close; the hive can be unloaded (either with regedit or reg unload or automatically for user profiles) once all the related keys are closed.
Users that log on with excessive privileges all the time IS a serious issue, but it's not one that has anything to do with the registry. If configuration was stored in.ini files, there'd still be the same issue of admins having too much access to them for normal usage.
The disclaimers on every Microsoft page mentioning registry editing are just standard CYA boilerplate. Notice that every EULA under the sun (the GPL included) also have similar disclaimers of liability. It's NOT dangerous to directly edit the configuration of applications and non-critical components.
Some people, such as you obviously, prefer the single binary store of configuration data in a propriatary format, others, such as myself, prefer everything to be neatly laid out on the filesystem in plaintext formats that can be viewed by anything that understands ASCII text.
You can't get away from binary formats. The filesystem itself is a binary database that requires special software (a filesystem driver) to access. The fact that registry hives and NTFS formats are proprietary is a result of running a proprietary OS.
On the other hand, I load up regedit, I have instant access to change, and corrupt both user and system wide configuration. Sure, it can be convenient to have everything in one spot, but am I in HKCU\Software\Microsoft\Windows\CurrentVersion or HKLM\Software\Microsoft\Windows\CurrentVersion?
This is like saying it's dangerous to have the entire file hierarchy in one place. How do I know if I'm in/etc or/home/me in the file browser, since I might delete anything accidentally. Come on.
Having the same structure for the system and user configurations where they overlap is called consistency. Besides, if you're logged on as a regular user (as you should be on both platforms), you have insufficent access to damage the system configuration in both cases. Deleting a key is no easier than deleting a file or directory. In Windows, both explorer and regedit ask for confirmation and won't let you delete things that are in use. Actually, it's easier to to accidentally unlink/etc than it is to delete HKLM\Software, because a rm -r -f/etc will succeed (as root) but you can't delete HKLM\Software (regardless of authority) because there are always open handles to it.
With plain text configuration files, any other OS capable of reading the filesystem is capable of accessing and editing the configuration files to fix them.
With registry hives, any other OS capable of reading the filesystem and registry hives is capable of accessing and editing the configuration files to fix them (only Windows for both AFAIK). Boot off your PE cd, open regedit and select Load Hive with the hive you're trying to edit, and you're in.
Also, backups with reg save are fast, simple, and provide a single file copy of the hive you exported that you can use as a replacement in case of disaster.
Which is why even some Microsoft products still don't use the Windows Installer! (MS Flight Simulator 2004 jumps to mind right away.)
I'm sorry. Microsoft is made up of many different divisions and they often disregard each other's rules.
Slashdot Mirror
As for tools, the Windows resource kits have linkd.exe, mountvol.exe, and delrp.exe (mountvol is standard since XP), and Sysinternals has junction.exe. Junction comes with source code. However, there is no GUI for reparse points, and as you pointed out, lots of apps are not prepared to deal with them.
No, ozzee knows exactly what he's talking about. NT 5 suppports filesystem "reparse points" which are closer to symlinks than hardlinks because they contain a pointer to the target file in the form of its filename.
When you try to open a file (or directory; just a special type of file), the filesystem checks to see if the file (or any of its path elements) is a reparse point. If so, the filename you're searching for is replaced with the target of the reparse point (a new filename), and the kernel starts a search for this new filename from scratch. If the open succeeds, the file you have open is the one targeted by the reparse point; the fact that it was opened via a reparse point is forgotten. It's the same as if you had specified the reparse target in the first place.
Let's say that you have two disk volumes: C: and D: which Win32 has pointing to \Device\HarddiskVolume1 and \Device\HarddiskVolume2.
A program tries to open C:\rp\f.txt.
Win32 converts this to \Device\HarddiskVolume1\rp\f.txt
The IO manager creates a file object F named \Device\HarddiskVolume1\rp\f.txt and asks the the filesystem mounted at \Device\HarddiskVolume1 to find it.
The filesystem realizes that \rp is a reparse point to \Device\HarddiskVolume2\dir.
The filesystem replaces F's name with \Device\HarddiskVolume2\dir\f.txt and returns F to the IO manager.
The IO manager starts the file search over again, this time asking \Device\HarddiskVolume2 to open \Device\HarddiskVolume2\dir\f.txt.
\Device\HarddiskVolume2 finds \dir\f.txt and the open operation succeeds.
As far as anyone knows, the program had asked to open \Device\HarddiskVolume2\dir\f.txt directly, because that is the name now associated with F.
If the program wants to delete/rename the file, it's now referring to D:\dir\f.txt, not C:\rp\f.txt.
If the program had really intended to open the reparse point itself, it had to specify FILE_FLAG_OPEN_REPARSE_POINT during the open operation. The Win32 DeleteFile() and MoveFile() (for rename) functions do not specify this flag, and so affect only the target of a reparse point.
In all the versions of Windows I know of, NTFS will only let you create directory reparse points, and the target must be to a local volume (not network). AFAICT, there are no technical reasons for these restrictions. I think a lot of the concerns are about how many apps would be incompatible with full symlinks.
At some point, I'm planning to write a kernel driver to try and bypass this check. Even if I couldn't get NTFS to use non-direcory, arbitrary target symlinks, a filesystem filter could intercept the open requests and enact reparsement itself.
One nice thing about Linux distros is that they have a lot of control over which software packages are accepted into their repositories (including necessary modifications), and those repositories tend to be quite large. Trying to pick up a piece of software NOT in the distro repository can be quite a pain, though.
Microsoft doesn't have nearly the same control over the software people sell for Windows. They do have a "Designed for Windows" logo system with a set of requirements (including unattended installation and LUA support), but they can't force companies to comply (if they made any effort to make them comply or require proper use of Windows Installer, people would cry monopoly; Linux distro repositories can make any requirements they want). How many apps that have that logo also have problems installing remotely?
I will say that UNIX software has a higher baseline quality than Windows software does, if only because UNIX users tend to be pickier than Windows users. This is not to say that both platforms don't have their share of high and low quality apps. Sure, and you can sometimes create
If you're complaining about 3rd party installers that don't use Windows Installer, they are not supported in the OS design, and it's hardly the OS's fault for their existence. It's not like UNIX platforms don't have programs that use non APT style installers that are fragile and need heavy modification and babysitting to work correctly.It's a bad mantra. If you follow some basic security rules on your network (#1: users don't get local admin for normal login), Windows is no more prone to malware than any other OS. If the app has a problem with these basic limits, the app is designed wrong (and not supported in the OS design (or any mutliuser OS design)). You wouldn't tolerate a user program that requires root on UNIX; don't tolerate apps that do the same on Windows. If an app can be easily ported to a UNIX, it is already following LUA (be it on a Windows or UNIXy host).
I don't get malware on Windows. I don't depend on anti-malware software, either. With a few precautions, my users don't get malware either. If they are, you're doing it wrong.
Are you sure it's only for the benefit of a few people? The people RECIEVING the jobs are certainly benefiting. With more jobs, and increased income lots of good things happen. You can't industraliaze but very slowly without industrial jobs from an outside source. The more outsourcing that's done, the faster the rest of the world can industrialize. I'd argue that an industrialized nation is far better for its people (and all people, really) than any of the more primitive alternatives. Globally, it's zero-sum at worst.
As for the country losing the jobs, it's painful for the people that were unrealisticly hoping that things would never change-- hoping that they would never have to learn more high level skills. The transition can be hard, but what change isn't? I'd argue that a country with many higher-skilled and workers is better than one with many low skill production workers (the primary type of job outsourced). We should be trying to increase the skill levels of our workers, and this means moving the lower skill jobs elsewhere. I know I don't want to do a repetitive, low skill production job. I want the total economic benefits that come from cheaper unskilled labor.
That's a problem, but it's a tax regulation problem, not a market problem. I think we should look into making second-class class citizenship official (with much lower taxation and tax funded benefits). Illegal immigrants exist and perform a real funciton, even if the state would like to be in denial. There exist many jobs that can only be done profitibly without the artifical constraints of minimum wage and extensive social benefits. Illegal immigrants fill this role. If you want to extract taxes from this, the first step is to legalize it.
Copyright is a government-enforced monopoly, contrary to a free market. This is an issue of state interests being corrupted by special interests. More socialization will only increase the opportunity for such corrution. And "depriving society of any real benefit of an invention"? Come on. Don't tell me that you don't derive any benefit from any of the pervasive copyrighted and patented things.
I am not familiar with this effect. In any case, this seems to stem from government tax funding (which is not a source of funding in a free market). It sounds like federal funds are being dispensed without requiring the researchers to release findings. This is the fault of whomever in the government is releasing the funds with lax requirements. The fact that such a gaping hole is being exploited is hardly suprising. Perhaps this is another case of special interest corruption?
In a purely free market, the government wouldn't be covering ANY medical expenses for the insurance companies to depend on. Besides, aren't all the insurance compaines up front about what things they cover, what things the state covers and how much you'll be paying? Why would you, as a consumer, want to buy insurance on something that the state covers anyway? If the insurance company offered two packages, equal except that one overlaps with what the state covers (and costs more for it) and one that doesn't overlap (and so costs less) which would you pick?
That depends on if I control the NAT router that has the real address. If so, I can and have on many occations forwarded TCP port 3389 (Windows remote deskop), TCP port 23 for SSH (with optional tunneling of 3389 over that) or OpenVPN on 1194 from either/both ends (from one end, even if I only control one public IP). It can be ugly, but the implicit non-public routability of my private network is good for security.
Yeah, they allow those useless tags but block some of the more meaningful (but anti slashdot revenue) tags like "slashvertisement" (for example); there really are some articles that are little more than product ads. If the tag was applied consistently and I had the option to hide those stories, I'd consider using it. Anyways, since they've already started the precedent of blocking certain tags, it'd make sense to add these useless ones to the list.
I think the only way to fix it would be to have a meta-tag system like the post moderation system. At least then, it would take a conspiracy of randomly selected users to get bad tags attached.
That and getting some good tags started.
PatchGuard is about stopping modifications to the kernel's internal structures, like the syscall table and the kernel's image. It has nothing to do with loading drivers that use only the kernel's public interfaces.
However, Microsoft HAS decided that only kernel-mode drivers signed with a SPC (software publishing certificate) can be loaded on x64. Microsoft doesn't charge anything for a SPC directly, but you do need to buy a cert from a commercial CA like Verisign. There is also an option that the user can specify during boot-up to disable the signature checks.
I, too, am worried about how inconvenient or expensive it will become to use free/open source drivers in Vista like Daemon Tools and OpenVPN. Although since I reboot so infrequently, I can live with setting the "Disable driver signature enforcement" every time I restart the OS. It's annoying, but usable. The thing is, disabling digital signature enforcement probably breaks all 'protected content' apps... I'm not sure if that's a bad thing or not.
Excel 5.0 was released in 1993 for Win16 and uses undocumented messages in one of the windows common controls. I was hoping for something a little more substantive, more recent, and involving the kernel.
In the InquireVisRgn comment doesn't mention anywhere that InquireVisRgn or the "private entry point" is used by anything but the OS itself. It's not an issue if the OS is using its own private interfaces.
Notice that in the article, they noted that there were about as many compatibility hacks for 3rd party software as there is for Microsoft software. 3rd party apps even got to have the behavior of undocumented functions modified for their benefit at times. Really, Microsoft shouldn't be obligated to keep 3rd party software that does bad things or uses internal functions working correctly (Apple certainly doesn't) but decided to bend over backwards for 3rd party apps in many cases. PatchGuard is all about Microsoft being able to change the kernel's internals without having to worry about breaking 3rd party apps that shouldn't be in there in the first place. That's true, but it doesn't relieve you from the burden of proof. Besides, when the nearly the entire NT4 source was leaked no one cried foul about all the undocumented functions offered to MS applications. I think they would have, if they could have. The only way to do IO from user mode is through one of the IO syscalls (NtReadFile, NtWriteFile, Nt[Fs|Device]IoControl, Nt[Query|Set]InformationFile, NtQueryDirectoryFile, Nt[Open|Create]File) plus memory mapped files (the Nt*Section syscalls). These functions are in fact part of the kernel's public, documented interface. If the code in question never reaches these syscalls, it's not doing any IO (unless you can show that there's some other way to perfom IO). Basic code traps can show exactly when these calls are being made.
This isn't a security hole. The fact that a process with admin privileges (yes, they're required for this) on the system can modify the kernel is something that can't be fixed by any means, on any OS (except via full TCPA). Microsoft knows that. Trying to protect the computer from malware/viruses that already have admin privileges is a joke. This is designed to make it such a pain for 3rd parties to continue modifying the kernel's internals (something that they shouldn't be doing in the first place) that they switch over to the public interfaces designed for the same purpose. Norton's crying that they have to clean up their code. Sophos already switched over.
What could you possibly be talking about? Direct disk access means bypassing the filesystem and reading and writing to the sectors directly. This requires administrator privileges for good reason: it bypasses file security, file locks and all the other nice things that filesystems do. No user application requires the ability to bypass the filesystem. Don't you need to be root to access a mounted block device on a UNIX? It's the same thing. The fact that it's possible to modify the kernel when you have admin privileges (and physical access for that matter) is hardly suprising, and in fact is unfixable (short of full TCPA).
PatchGuard is only there to discourage apps that hook the syscall table (an inherantly unsafe operation) and make other modifications to the kernel's private, volaitle internal interfaces. When Windows NT was written, the MS devs never expected 3rd party devs to go poking around with the kernel's private interfaces, and are rightly disgusted when those 3rd party software programs cause problems because of it. Compare this to Linux: you are free to maintain your own custom build of the kernel, but in the mainline, all the kernel interfaces are so volaitle, every minor revision is binary incompatible with the rest. You'd never get a device driver accepted into the mainline if it depended on private interfaces that break every revision, even on a source level. Microsoft is well within their prerogative to make changes the Windows kernel's internal, private interfaces. This doesn't work too well when 3rd party apps are dependent on them never changing, especially when Windows crashes because of it. PatchGuard is a technical speed bump to make it harder for 3rd party software companies to screw with the kernel's internals. Microsoft knows that it's an unwinnable arms race, but hope that the 3rd parties will decide it's just easier to stick to the kernel's public interfaces. Microsoft is willing to create new stable public interfaces to support the necessary behavior.
The only thing I can think of that you might be talking about for reduced performance is if you meant no intermediate buffering when you said "direct disk write". The FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH buffering options are unrelated to direct disk access (which actually means bypassing the filesystem to access the block device directly). Write through and unbuffered IO aren't going anywhere.
As for special hooks that MS applications get into the OS that no one else gets, how about an actual example?
Have you seen Clock in a Linux Guest Runs More Slowly or Quickly Than Real Time? It can happen when the 2.6 kernel requests more interrupts for the purposes of clock updates than the host can provide, especially if the host is Windows. The kernel will try to compensate for lost ticks, but this doesn't always work correctly. The main solution is to set the clock interrupt rate back to 100Hz like it was in the 2.4 series (requiring a kernel recompile).
Er, not if you go back further:
NT 3.1: 3 service packs
NT 3.5: 3 service packs
NT 3.51: 5 service packs
NT 4.0: 6 service packs
NT 5.0 (2000): 4 service packs
NT 5.1 (XP): 2 SPs so far
NT 5.2 (2003): 1 SP so far
Microsoft has never released a service pack once a product reaches the extended support phase, and they usually stall once the deadline is near.
Although they aren't service packs, Win95 had 2.5 OSRs (not upgradable AFAIK), 98 had 2 Editions, and ME had only one release.
So I guess the SP count peaked with NT4 and troughed with XP and 2003. Maybe the count will start going back up now with 3-4 service packs for Vista?
The driver model isn't THAT different; it's not hard to write drivers that are source-compatible with both the 64 and 32 bit archs with only a tiny amount of conditional compilation. Drivers that used to patch the syscall table and can't now in x64 should never have been doing it in the first place. All the Vista flavors (and I agree that there are about 6 too many) use the exactly the same kernel and drivers.
The main reasons they aren't implementing the same thing in 32-bit Windows is because of "limitations of the 32-bit architecture" that apparently don't let them do what they want, and since a lot of programs already patch the syscall table in 32-bit windows, it'd break compatibility with a lot of software to change it now. Binary compatibility for drivers that patch the syscall table on 64-bit Windows isn't an issue because 64-bit Windows for AMD64 has always prevented syscall patching. They figure that the 32->64 bit change is big enough to pile on some more changes, like this.
This has more to do with system stability than it does for security. Many syscall interceptors are not multiproc safe or do bad things: if the computer bluescreens because of a poorly written syscall interceptor, Microsoft gets blamed for writing unstable software. The syscall interface is considered an internal interface, not to be tampered with by outside parties because its behavior has subtleties not documented, and could change. This is a technical enforcement of that policy.
Microsoft executive clarifies recent market confusion about Vista Security
I'm not talking about the kernel in particular, although its design is an important part. I think I'm talking about the same thing you are: things like the conventions, the basic abstractions and how they're presented, across all the OS's core components. For example, most kinds of IO are inherently asynchronous: NT and UNIX implement async IO quite differently, yet both provide a similar synchronous interface to IO (with an emphasis on caching to achieve reasonable performance) because that's the way most apps process data. IMO, NT's async IO abstraction is much better than UNIX's.
For that matter, the file abstraction is something that both UNIX and NT use for many of the same things, namely disk files (local and remote), pipes, sockets, and devices. On the other hand, NT doesn't use files to present process information: since by convention everything is an object on NT (a superset of the UNIX "everything is a file" convention, since files are also considered objects-- along with many things UNIX doesn't consider files, like mutexes), you just query the properties you want from a process object. Object property interface vs filesystem interface.
Before you say, "Well, at least it's better than Windows!" the part of modern Windows that compares to OSX's Darwin core is the NT core. Both platforms have the majority of their software above the core level, but my question isn't about that. I want to know why popular opinion seems to hold that simply being UNIX = good and great while anything else is implicitly lesser.
I'd put the NT core's VMS inspired design (or VMS itself) up against the UNIX System V or BSD designs any day. For that matter, I'd put their modern implementations up against one another too (NT 5.2 kernel and system (of WS2003), OpenVMS 8.3 and Linux 2.6, OpenDarwin 7.2, OpenBSD 3.9, etc.). I'm sure that there are other OS designs out there worthy of comparison, too. I'm just disappointed by the UNIX = The One True OS rhetoric.
Windows NT's security model is quite powerful and reusable but almost all devs (Microsoft's own included) misuse or ignore it, and we all know how well that's working out...
I don't think I've ever become confused as to if I was in a user's or the system's software key. The old regedt32 uses seperate windows with the Win32 root key in the title bar and regedit shows the current path in the status bar. I tried deleting a key in regedit and it asked "Are you sure you want to delete this key and all of its subkeys?". Regedt32 asks "Registry Editor will delete the currently selected key and all of its subkeys. Do you want to continue the operation?" They both have similar warnings before deleting a value. I'm not sure why you aren't seeing these warnings... I didn't think there was any way to turn them off.
It doesn't take THAT long to boot a PE CD. Much of the time is spent loading drivers for obscure SCSI controllers that you don't have, and that behavior can be avoided. There exist some alternatives to Microsoft's registry editor (all of the required APIs are public); it's just that the built in editor exposes all the needed functionality, and it isn't used often enough to need extra features like the high level text editors have. The only reason you need a GUI to edit the registry is that no one has written a text mode registry editor, or for that matter one that doesn't depend on Win32 (if you depend on Win32, you may as well use its GUI).
IDK if I mentioned it in this thread, but you can back up/restore user profiles with ntbackup, and backup specific registry keys with reg save and restore with reg restore. Regedit also provides save/restore functions in the file menu. It doesn't matter if the profile is in use-- in fact, it HAS to be loaded for reg save/restore. Ntbackup will automatcially detect if the profile is loaded or not. When a user logs off, all references to the profile are supposed to close, but sometimes poorly written services won't cooperate. You may see event log messages about how a user's profile couldn't be unloaded right away because of this.
Registry hives are opened by the kernel; the file handles are in the SYSTEM pseudoprocess. Don't forcibly close them or you're likely to cause a bugcheck. You can try to find registry key handles in user processes to close; the hive can be unloaded (either with regedit or reg unload or automatically for user profiles) once all the related keys are closed.
Users that log on with excessive privileges all the time IS a serious issue, but it's not one that has anything to do with the registry. If configuration was stored in
The disclaimers on every Microsoft page mentioning registry editing are just standard CYA boilerplate. Notice that every EULA under the sun (the GPL included) also have similar disclaimers of liability. It's NOT dangerous to directly edit the configuration of applications and non-critical components.You can't get away from binary formats. The filesystem itself is a binary database that requires special software (a filesystem driver) to access. The fact that registry hives and NTFS formats are proprietary is a result of running a proprietary OS.
Come on.
Having the same structure for the system and user configurations where they overlap is called consistency. Besides, if you're logged on as a regular user (as you should be on both platforms), you have insufficent access to damage the system configuration in both cases. Deleting a key is no easier than deleting a file or directory. In Windows, both explorer and regedit ask for confirmation and won't let you delete things that are in use. Actually, it's easier to to accidentally unlink
Also, backups with reg save are fast, simple, and provide a single file copy of the hive you exported that you can use as a replacement in case of disaster. I'm sorry. Microsoft is made up of many different divisions and they often disregard each other's rules.