If you look at the "altruistic" villains in her stories, their altruism is false or twisted - their evilness does not come from simply acting altruistically, but because they throw away their own wealth and the wealth of the entire nation when they cannot afford it.
Or hunger for power, be able to acquire it under some nefarious means, but be too stupid to understand it and use it effectively. Few people are that dense, yet able to get and keep power.
As with any philosopher and philosophy, one does not have to adopt Objectivism in its entirety to believe it has merit. I agree that a devotional attitude to Rand makes for a small and worthless mind, but an absolute following of any philosopher produces small and worthless minds. I try to pick through her arguments, extract the truly rational, and leave some of her rants and tirades behind.
Exactly. I'm always on the lookout for insight, regardless of the source. I trust myself to dissect the various propositions and ideas, and to have better confidence in the ones that are true. Rand makes some good points, but also supports serious fallacies. It's definitely possible to keep the good and toss the bad (to the extent each idea can be said to be either), given some thought, in any domain of knowledge. To borrow one Rand saying: "There are no evil thoughts except one: the refusal to think." The hallmark of the zealot is to refuse to think about the position they've taken and the position of others (even the existence thereof), e.g. by saying that a certain philosophy or person is pure good or evil.
But all the time she runs into other people in her profession who do not have the same motives, they just want a steady paycheck, or the nursing profession is just a stop on their path to some other career - they may or may not act professionally, will pass problem patients to others to avoid hassle, they may be lazy in how they fill out paperwork for the patient, and generally won't go out of their way to do anything for them that doesn't immediatly equal more pay or a censure from the boss. These people stagnate, making themselves and everyone around them miserable, or they realize their problem and quit.
Absolutely. IIRC, the first rule in career counseling is to find a job that you love to do. Anything else and you'll do it badly and be unhappy. I think one of the reasons that Americans tend to be workaholics is that by-and-large, each of us can find work doing something we love to do. We don't have castes, exclusive guilds, state mandated jobs, familial apprenticeships, or anything that determines most people's occupation against individual choice. If you can afford a college education, you can do almost anything. We work because we like to. The fact that it benefits ourselves and everyone around us is somewhat of a side-effect.
Since FUSE requires a UNIXy environment for the user mode filesystem modules, I would think that SFU would be quite useful for that. The main alternatives that I know of are to use Cygwin instead (which has its own problems) or re-implement enough of a UNIX environment to compile the required FS modules (which would be a lot of work). IDK how Cyberax was planning to do it, but SFU really is the best option IMO.
This page has a listing of some free/open windows drivers, including three for ext2, one FFS, ReiserFS, AFS, and two user-mode driver system frameworks. They also have a clean-room free ntifs.h, although I prefer a more ReactOS style environment, which includes FAT and CDFS drivers. For that matter, I'm about 70% into writing my own.
The IFS kit is now $109 and its documentation is now available online, including a design guide. The only thing about it is that the IFS docs concentrate on file system filters, not full FS drivers. Even so, if you implement the major IRP functions one at a time (read, write, enum directory, etc: each of which is documented), it's really not bad. Some of the functions are complicated (moreso than a VFS FS) but writing regfs has gotten me to the point where I can see how it all fits together. I find the architecture very usable, if overly complex. I haven't had to put in any magic app-specific hacks (at least not yet) to get them to work, even for Explorer.
Hmmm, you seem to have discovered a very perplexing bug; I did fix a problem with parsing certain types of relative paths (the updated version is online), which fixed the file not found error, but left me with a new one:
As far as I can tell, for both echo and type, cmd.exe is opening the value successfully, and then not doing anything with it... in fact, it seems to be forgetting about the file handle entirely, allowing it to leak. What's really perplexing is in the case of echo text>file, cmd.exe opens file successfully and does absolutely nothing else with it. I can't imagine what possible input regfs could be giving cmd.exe from a single successful open operation to make it abort silently.
Notepad will not be able to read or write until memory mapping is supported in some form (it'll say "%1 is not a valid Win32 application" which is a Win32 oversimplification of STATUS_INVALID_FILE_FOR_SECTION(section meaning memory mapping)). Unfortunately, there really isn't a clean way to implement memory mapping because I can't lock registry data, and the registry itself doesn't support memory mapping. It's listed in regfs limitations. I've been testing mostly with wordpad and mspaint, which seem to work fine.
Speaking of limitations, there are problems that may prevent regfs from ever being a good enough replacement for using the registry API directly in general usage. For one thing, registry value types don't have a good analogue in a filesystem, except file extensions which aren't a good idea to translate into value types because you can have multiple files with the same base name differing only in extension but you can't have multiple values with the same name differing only in type. As soon as an app tried to create two files with the same base name, it'd be rudely surprised to find that one had overwritten the other. Even so, there may be better ways to work around those problems that I haven't thought of.
The only reason I can think of for echo and type to fail is that they try to memory map but silently fail to... although even then the memory manager should be sending a preliminary paged read (but isn't) like it does for notepad. I could definitely use help debugging the echo and type bug, if you're interested. Feel free to e-mail me. If there's enough interest, I'd be happy to move to SourceForge or Google Code.
I have thought about porting FUSE in the past, since it'd be a great way to enable lots of filesystems in Windows but haven't gotten out of the planning stage. I'd be very interested in helping to make that happen. I have some experience in writing Windows NT filesystem drivers.
I don't know how you've planned the userspace, but I'd suggest that you make it NOT dependent on Win32. It'd be much easier to implement features like fork (which Win32 doesn't support, but native processes do). Also, native process programming follows a lot of the same conventions that kernel programming does; the code would be more consistent and lightweight. Besides, it seems unlikely that FUSE would require Win32-specific features.
Please let me know if you get a source repository up.
Sure, people SHOULD be able to distinguish between Microsoft OS applications and third party ones, but there are lots of users who think everything on the computer is "Microsoft". I've come across those people before, and it's not pretty.
Supposedly, Microsoft does in fact send those crash reports back to ISVs and they sometimes fix their products because of it. They could definitely make that dialog clearer as to what happened and who is at fault, though.
Even Microsoft documented at least one! Here's a comment in the Win2K source code that got leaked onto the net a few years ago:
private\mvdm\wow32\wcntl32.c:// These undocumented messages are used by Excel 5.0
Wow32 is Windows on Win32, i.e. the Win16 API. Excel 5.0 was released in 1993. Microsoft wasn't an OS monopoly in 1993. Your one example is 14 years old-- too old.
You can see "documentation" for many of them on the Sysinternals site.
For one thing, that site is from ntinternals.net by Tomasz Nowak, unrelated to Sysinternals by Mark Russinovich and Bryce Cogswell, which was recently bought by Microsoft.
The functions on that site are indeed largely undocumented (many of the functions are officially documented as part of the DDK, but only for use in kernel mode). The functions are considered private to the OS. No one is accusing Office or other Microsoft non-OS products from using those functions. They are only used to implement the Win32 API and some system services. I, too wish that they would document those since they are considerably cleaner and more stable interfaces than the Win32 equivalents, but please don't confuse private parts of the OS with special functions for MS applications.
Not that they're likely to do it, but what if one of these had a worm come along exploiting it? The quick and obvious fix would be to simply remove it.
It'd be very infeasible for them to remove any of those functions; they're used heavily inside the OS to get things done. Never has a working function in the native API been removed or seriously changed. It'd be like removing the mmap() syscall from the Linux kernel in response to the mmap() vuln they had a while ago.
Whenever one uses pointers to members, one always winds up pairing it with a context pointer (this) anyway.
That's like saying that whenever one uses a function, one always winds up combining it with arguments: therefore function pointers are useless alone, they should always be bound with arguments when created. A pointer-to-member provides one more level of indirection than a delegate by making the target object a parameter. This parameter can be bound with an auxiliary class. C++ provides the support to make such classes behave very much like first class types.
Pointers to members are useful in their own right.By themselves, I don't agree. I've almost never seen any use for them in isolation.
I've found them useful for providing access to a private field or function of my choosing to a second class that will use it on multiple objects, i.e. an alternative to friend. The best part is that the target class can dispense different member pointers to provide different functionality, without modifying the calling class. An object can bottle an operation to be executed on an entire list of its peers, executed by a third party that needn't be privy to that operation.
No, only a subset, as unlike a true delegate, the pointer to member pair is bound to the class type. A delegate is bound to only the function signature.
A simple pointer to member is bound to the class type. However, any good C++ delegate class will not make the target class a part of its type: every compiler provides a way store a generic pointer to member, regardless of which class its a member of. As long as the delegate class guarantees that the class type and member pointer types match at runtime, it can safely cast to a generic pointer to member type. Users of the delegate class needn't worry about the details. The only remaining type information is the function signature.
This means that delegates can be nested functions, too. The various C++ attempts to do this require a lot of complexity and overloaded functions.
Any good delegate implementation will support static functions. It would be nice to have directly nested functions, but you can still have functions nested in classes nested in functions.
The only function I can think of overloading on a delegate class is the parenthesis operator to make invocation pretty. If comparison would be useful, the default binary comparison operator would be sufficient. I once created a Sink class that implements single argument delegates in 48 text lines. It only overloads operator (). I wouldn't call that complex. And it isn't hard to use:
struct C { int _x; C(int x) : _x(x) {} void f(int y) {cout << _x + y << endl;} };
void f2(int y) {cout << y << endl;}
void g() { C c(6); Sink<int> d(&c, &C::f);//a member function d(5); Sink<int> d2(&f2);//a non-member function d2(11); }
Granted, functions with variable arguments will require more work on the part of the library writer, but as a user of the class you don't have to worry about that.
That's an odd thing to say about a language that is, by far, the most complex core language ever devised.
Complexity isn't the same thing as implementing things in the core language that could be done in a library. Besides, there are definitely other language specs massive in size compared to C++'s: for example, Common LISP's specification is quite massive (about 1300 pages; there's a joke that Scheme LISP's entire language spec fits inside just the INDEX to index to Guy Steele's "Common Lisp: the Language, 2nd Edition"), and Perl certa
Right to begin with? What's wrong with C++'s implementation?
Pointers to members are useful in their own right. A pointer to member plus a pointer to the base object provides all the functionality of function and field delegates. One of C++'s greatest strengths is that the base language isn't weighted down by functionality that can be implemented in libraries, e.g. text strings. The less redundant pieces that go into a language, the better: libraries are much better for multiple alternatives.
Delegates are not just function pointers, they are a pair consisting of a context pointer and a function pointer. The closest thing C++ has to it are member function pointers, which are far more difficult to work with.
Ok, how big are your registry hives really? The machine's hives are the extensionless files in %SYSTEMROOT%\System32\config. Your user's registry hive is in your profile: %USERPROFILE%. I really don't think that installing a new piece of software will contribute megabytes to the registry's size.
Furthermore, the registry has never used non-paged memory to load its hives, and since XP mounted hives are only loaded in 64k pages as needed.
You mean these? Those numbers are (base) build numbers. You use them to find out what current build of.NET you have according to the revision's base build number. Base build numbers are a recent Microsoft tradition of allocating version numbers. If this was stored in a text file, they'd still be the same numbers; the same data.
[...] cryptic keys such as: "{874aa5f2-3745-9e23-8a39-8972bcb1455e}" - care to tell me what that means???
COM uses DCE UUIDs (aka GUIDs) to identify a myriad of classes, interfaces, libraries and such without risk of textual namespace collision. A GUID is the primary key of these objects. In a hierarchical database, it makes sense to have a directory in order to lookup those components by their PK. Note that components that have names can be found directly in HKCR, with a pointer to the component's GUID (sometimes called CLSID).
COM has opaque random binary keys to identify components. Whatever database stores information for COM will have to include those keys, be it in a text or registry format. Besides, a text file for each program to read in its entirety to lookup a handful of relevant components in a linear search would be incredibly slow. The registry maintains B- trees for fast lookup. You can only maintain indexes in a binary database.
Instead of having to hand-compute bitmasks, you use words.
Yes, some apps aren't terribly friendly to hand-editing. Some are. Regedit lets you enter numbers in hex, which is pretty good with bitfields. Most Microsoft entries that store config are readily hand editable. It all depends on the person who decided the format their app uses in the registry: they can choose to be friendly to manual editing or not. It's the same way for text files. I will say that UNIX has a generally better tradition of hand-edit friendly config files.
While you CAN use regedt32 (regedit) to partially "manage" settings, the majority of the contents are useless as the registry is first and foremost designed to ONLY be managed via the various applications via the API it and Not by humans.
Guess what: most users never want to see the inside of a config file or registry key. If there are options, there should be a friendly dialog box associated with it, with help, tooltips, validation, dynamic lists of choices and all the other nice things that only work in an interactive interface.
If the registry was really meant for computers only, there'd be no text strings naming keys and values. EVERYTHING would be referenced in GUIDs and private enumerations. Text is only necessary for interaction with humans. The registry is meant for both programs and power users to interact with. The filesystem's design is very similar. In fact, you could say that the registry is a highly specialized filesystem for use with a very large quantity of directories and files with with tiny values.
If you want to see the next step, look at the USAF's SDC program. They are using WinXP with some sort of Trusted Computing module. Unless an executable is digitally signed by the USAF, it will not run.
IDK how SDC is implemented, but XP has a built-in capability to only run signed programs via Software Restriction Policies. An admin can set the default rule for binaries to disabled, and only allow specific ones identified by path, hash or certificate to be loaded.
Most of the other restrictions you mentioned can also be accomplished with the built-in group policies.
Ok, upon actually reading the articles, my first paragraph is off: although the display part of MessageBox() is implemented entirely in the client side library, it may ask CSRSS to display the box instead. It's CSR that's mishandling that request in some weird circumstances. This isn't the only long standing bug of its kind in CSR. I sorta get the impression that no one at Microsoft really wants to touch the old CSR code (and may not even be competent to). The thing about "\??\" sounds like some debugging or obsolete piece of code that was written once and never read again. This is possibly a good case study for something that open source onlookers would've noticed as a bogus special case while browsing code.
My point about how apps should sanitize data from untrusted sources before passing it to internal library functions still stands, though... just not as much in this case.
For one thing, MessageBox() is implemented entirely in user32.dll, a client library which runs directly in the client process calling the function. CSRSS and win32k only implement lower level primitives like windows and display contexts (Here's a list of both the service tables; scroll down to win32k.sys to see all of it's functions). MessageBox() uses those to create a new window with the specified buttons and text on the fly with those primitives; the vulnerability is inside that code. There's no reason to put MessageBox() on the server side (i.e. in CSRSS or win32k). MessageBox() is not a path to privilege escalation.
However, this still could be a vulnerability if any programs pass arbitrary user data directly to MessageBox(). This seems to be like the GDI+ vulnerability: another client side library that wasn't prepared to deal with bad data coming from another module within the same process. The problem is that that bad data may have originated from outside the process, being passed on to the library verbatim. Shared libraries don't usually check their interfaces for security heavily because they weren't expecting to be handling data from the outside world-- only data coming from within the process.
The convention always was that the onus for providing correct data to a library was on the caller. If the data is bad, the only process that is hurt is the one that provided the bad data-- no escalation because a process can only hurt itself. The idea was that since only external interfaces are connected to untrusted sources like the outside world, only external interfaces need rigorous checks. Traditionally, library functions were used only as internal interfaces. As programs become increasingly abstracted, they pass their data more directly to their libraries. The problem occurs when a library trusts the calling application to validate data, when the application thought the library was going to do it.
Another thing this is similar to are SQL injection vulnerabilities. When SQL was created, only operators and services trusted to some extent by the system could write queries. When the line between data and query was blurred with various forms of dynamically generated queries, poorly written front-ends allowed user data to bleed directly into the SQL statements that (used to be) trusted.
As with SQL injection, I'd say that the onus should still be on the caller to provide sanitized data to naive functions like MessageBox(). It doesn't matter that MessageBox() will do bad things if it gets bad data; any program that talks to untrusted sources should sanitize incoming data BEFORE it gets to such functions. Javascript allows you to pop up a message box, but it's the browser's job (since it's the one talking to the outside source) to make sure that the text in the box is clean before passing it on.
As long as front-end program code doesn't prematurely abdicate it's responsibility to sanitize incoming data, vulnerabilities like this one and the GDI+ one won't be an issue. The only time they can pass that responsibility on is when the library states that it can accept it, either explicitly or implicitly by being an external interface (like a network service).
Even if we don't have free will, our actions still have causes in the real world; people's actions can still be affected by laws and potential punishment even without free will. Someone who thinks of killing another for the sake of jealousy will still consider the consequences of that act imposed by the state.
Besides prevention of crime, laws are useful to denounce certain activities as not condusive to a stable, productive society. Even without free will, it'd be useful to figure out what things would tend to damage society (along with the things and people in it), make a list of them and their severity and advertise it.
Even without free will, rehabilitation is possible. Some people's destructive behaviors can be fixed enough so that they can be let back into society. Actually, free will could make rehabilitation more difficult because it implies that there is a part of a person's nature that cannot be modified. I'm not suggesting that people be brainwashed (because it's too easy to abuse), but rehabilitation is easier in theory if people's behaviors are more deterministic.
As for retribution, i.e. revenge, how is that helpful? How does it specifically help someone (or society) to accomplish revenge?
In any case, good post. Scott Adams (writer of Dilbert) has had some interesting posts on (the lack of) free will on his blog.
Windows NT 3.1 was released in 1993. It had fully protected memory, strict user/kernel separation (i.e. only the kernel can touch hardware devices), and fully preemptive multitasking (even for threads running in kernel mode). Windows NT 3.1 marked the first implementation of Win32. NT wasn't marketed as a consumer OS until version 5.1 (XP) in late 2001, but NT 3.1 was offered as a general purpose OS with plenty of overlap with DOS/Windows 3.1. It could run many Win16 and DOS programs, as long as they used Windows, DOS and BIOS interfaces to access hardware (as opposed to 9x which usually didn't care).
I've never had an NT installation (including modern versions like 2000, XP and 2003) go 'stale'. We can both cite endless examples of it occurring and not occurring, but the more important questions are about understanding this phenomenon: What are the symptoms of a stale installation? What are the specific causes? How can adding and removing software lead to reduced performance? If your answer is "I don't know, it just happens" then how do you really know it's happening?
Here are the worst things I can think of a bad uninstaller leaving:
Files are left over in system directories (e.g. %SystemRoot%\System32) that aren't used anymore. NTFS uses B+ trees to index directory entries. You'd have to at least double the number of entries to cause a noticeable slowdown. The leftover files will waste space, but they'd have to be hundreds of megabytes to impact system performance.
Keys are left over in the registry. The registry uses B-trees to index key and registry data. The HKCR tree alone contains about 94 thousand keys and 34 thousand values in a fresh XP install. There would have to be at least an increase of that magnitude to impact performance.
References are left to non-existent shell extensions and startup items. It'll only take Explorer one failed call to CreateProcess or LoadLibrary to figure out that the items are broken. From those functions, the OS would only have to perform a few failed file lookups to realize the files are non-existent. Fixing this kind of thing is easy with autoruns.
Broken COM references. Like other leftover registry keys above, there'd have to be an awful lot to cause slowdown. The only time I can think of that a program would actually list all of the COM components is when an IDE like Visual Studio is giving you a list of available components. In all other cases, a program will already know what its looking for and be unaffected by unrelated entries.
If there actually is some source of inevitable slowdown after a Windows installation has seen use, there has to be a cause. If no one can tell what that cause is, you'll understand if people like the parent and I call bullshit on such claims.
I knew about the forcedeth driver, but my statement that it wasn't ready is definitely out of date. All I can say is that it wasn't ready back when I was building the machine. I can't figure out if it's out of the "experimental" state yet though (not that it matters; I'd use it now). Thanks for the update.
Microsoft writes lots of drivers. They have drivers for all sorts of standardized hardware with open specs, like OCHI USB controllers. What Microsoft doesn't (and can't short of reverse engineering) write drivers for are pieces of proprietary hardware. The same reason that the only good Linux nVidia video drivers are a binary from nVidia is the reason that Microsoft doesn't write nVidia's video driver either.
Of the 118 driver modules currently loaded on my system, 100 of them are (C) Microsoft Corporation. The others are 5 for VMWare, 2 for my nVidia video card, 1 for the nVidia nForce MCP net adapter, 1 for the Realtek 650 sound, 1 for the OpenVPN virtual TAP adapter, 1 for the crappy Macromedia safedisc copyprotection driver, 2 for Daemon Tools, 1 for Process Explorer, and 4 for the cd burning software. Of the non-Microsoft drivers that are supporting real hardware, that's 4 drivers for 3 devices. There are only three devices on my system that Microsoft didn't write drivers for. If Linux were running on this system, I'd want the binary nVidia drivers for video and networking (AFAIK nForce2 networking still isn't supported in the mainline. It definitely wasn't when I built the machine).
Microsoft definitely has a drivers division. I do agree about Microsoft fixing the wrong things most of the time in their OS, though.
Incorrect. Canadians are free to purchase additional coverage over and above the provincial plans at their own cost or with costs shared by employers. The provincial plan is a *baseline*, not a *ceiling*.
The plan can hardly be both complete and in need of supplemental plans. It's nice that you can add more, but the point is that the vast majority of expected expenses already have a fixed plan, one that an individual has no choice but to comply with.
You clearly don't know about how private insurance works, if you think "efficiency" has anything to do with it. Private insurers eat up to 30% (industry average of between 10% and 15%) of all premiums in "overhead" costs (salaries, buildings, processing, etc.), compared to less than 5% for public insurers...
Those are good references. Thank you for citing them. What concerns me more than overhead percentages from the insurers is the amount that hospitals and other care providers spend dealing with the myriad plans and haggling to get claims filled, compared to the simplicity of Canada's state-run plan. As long as the socialized plan stays an order of magnitude simpler than a sea of insurers (and government programs by no means always stay simple, look at the IRS), then I have to admit that socialization would result in a great increase in efficiency. I still don't like the idea of being locked into a single plan, but it does seem to be better than the overly complicated mess the US has now. I'd be happy if the government offered, say, 2-3 plans ranging from comprehensive coverage to high-deductible + a health savings account. The providers could still submit a simple form; the differences would only be in the last stage of payment and a part of a person's tax mode.
What's far more amusing in your stance, however, is your willingness to trust profit-motive-driven corporations with knowing what's best for you as an individual... which have no accountability to you whatsoever, rather than trust someone who is ultimately accountable to the citizenry such as elected provincial officials and the offices they oversee.
If I'm paying the insurer, they're absolutely accountable to me because I can immediately stop paying them and move to another company if I'm not happy with them. Money is the lifeblood of corporations. Ideally, the customers control its supply based on how satisfied they are compared to the alternatives. The system only breaks down when people don't have a choice, or don't have the proper information to make a choice.
While I can switch insurance companies in a month, tops, politicians are only held accountable at election time, if you're lucky. People have to actually be aware of the issue, at election time, and not be blinded by hot-button issues or mindlessly fill in their lifelong party bubble on the ballot. Capitalism puts the choice for my care directly in my own hands; I don't have to depend on the whims of the majority. Most elections are about 1-3 hot-button issues. Gross inefficency has never been one of them, AFAIK. Look at the US's national debt: a corporation would've been bankrupt long ago, but the government can print money and borrow way past its means. Where's its accountability for that?
(you don't pick your health plan--your employer does, and even then they can only pick what plans are *offered* by the insurance companies)
That's a problem with the employers making the choice for you. By itself, it's no different than the state making the choice for you. Either way, the choice is made by someone "above" you. You can always buy supplemental insurance if you want...
There are A LOT of health plans available. I'd be very surprised if you were unable to find one that suits you. There are so many, the overhead of interfacing with them generically is causing an excessively huge overhead, a conclusion I share with your sources.
You have free healthcare? Where do I sign up. I currently pay nearly $1,000 a month for health care, not including my out-of-pockets and co-pays.
Canada.
It's not free. You're still paying for healthcare, just more indirectly. The OP knows exactly how much he's paying for healthcare. You don't. The OP has a choice about which coverage option to choose, and can change if it's not the best option given individual circumstances. You don't and can't.
Things don't come for free. It's all about how you choose to pay for it. Personally, I'd much rather have the choice in my own hands, rather than in the hands of a politician who can't possibly know what's best for me as an individual, and has only weak standards of efficiency to live up to.
From what you're saying, Costco is more profitable than Sam's Club because Costco's management understands the value of employees in the long term, while Sam's Club's management doesn't. This is an issue of management competence, not "Liberal" vs "Republican". Both companies are interested in making money, it's just that Costco is better at it because they better understand what's valuable in the long term.
Since Costco management understands the real value of its employees and customers, Costco receives many rewards, including lower employee turnover, better customer loyalty and higher total profits. Sam's club management doesn't understand, and so are doing poorly. This is capitalism at its best: competence being rewarded.
There's no conflict between long term profits and making the world a better place. People have value. Those who understand that will be more profitable.
I agree that you should have the proper privileges (traditionally root on UNIX, SeBackupPrivilege on Windows) to back up files belonging to other users or to the system. You shouldn't need them to back up files belonging to you, owned by your user account.
NTBackup used to let you back up your own files, or any other files you have read access to. Last I checked, Vista Backup won't run at all unless you are an administrator. I say "used to" because the NTBackup version with Volume Shadow Copy support (from WS2003) isn't included with and won't run on Vista.
Slashdot Mirror
Great post. You deserve better karma
Since FUSE requires a UNIXy environment for the user mode filesystem modules, I would think that SFU would be quite useful for that. The main alternatives that I know of are to use Cygwin instead (which has its own problems) or re-implement enough of a UNIX environment to compile the required FS modules (which would be a lot of work). IDK how Cyberax was planning to do it, but SFU really is the best option IMO.
This page has a listing of some free/open windows drivers, including three for ext2, one FFS, ReiserFS, AFS, and two user-mode driver system frameworks. They also have a clean-room free ntifs.h, although I prefer a more ReactOS style environment, which includes FAT and CDFS drivers. For that matter, I'm about 70% into writing my own.
The IFS kit is now $109 and its documentation is now available online, including a design guide. The only thing about it is that the IFS docs concentrate on file system filters, not full FS drivers. Even so, if you implement the major IRP functions one at a time (read, write, enum directory, etc: each of which is documented), it's really not bad. Some of the functions are complicated (moreso than a VFS FS) but writing regfs has gotten me to the point where I can see how it all fits together. I find the architecture very usable, if overly complex. I haven't had to put in any magic app-specific hacks (at least not yet) to get them to work, even for Explorer.
Hmmm, you seem to have discovered a very perplexing bug; I did fix a problem with parsing certain types of relative paths (the updated version is online), which fixed the file not found error, but left me with a new one:
As far as I can tell, for both echo and type, cmd.exe is opening the value successfully, and then not doing anything with it... in fact, it seems to be forgetting about the file handle entirely, allowing it to leak. What's really perplexing is in the case of echo text>file, cmd.exe opens file successfully and does absolutely nothing else with it. I can't imagine what possible input regfs could be giving cmd.exe from a single successful open operation to make it abort silently.
Notepad will not be able to read or write until memory mapping is supported in some form (it'll say "%1 is not a valid Win32 application" which is a Win32 oversimplification of STATUS_INVALID_FILE_FOR_SECTION(section meaning memory mapping)). Unfortunately, there really isn't a clean way to implement memory mapping because I can't lock registry data, and the registry itself doesn't support memory mapping. It's listed in regfs limitations. I've been testing mostly with wordpad and mspaint, which seem to work fine.
Speaking of limitations, there are problems that may prevent regfs from ever being a good enough replacement for using the registry API directly in general usage. For one thing, registry value types don't have a good analogue in a filesystem, except file extensions which aren't a good idea to translate into value types because you can have multiple files with the same base name differing only in extension but you can't have multiple values with the same name differing only in type. As soon as an app tried to create two files with the same base name, it'd be rudely surprised to find that one had overwritten the other. Even so, there may be better ways to work around those problems that I haven't thought of.
The only reason I can think of for echo and type to fail is that they try to memory map but silently fail to... although even then the memory manager should be sending a preliminary paged read (but isn't) like it does for notepad. I could definitely use help debugging the echo and type bug, if you're interested. Feel free to e-mail me. If there's enough interest, I'd be happy to move to SourceForge or Google Code.
I have thought about porting FUSE in the past, since it'd be a great way to enable lots of filesystems in Windows but haven't gotten out of the planning stage. I'd be very interested in helping to make that happen. I have some experience in writing Windows NT filesystem drivers.
I don't know how you've planned the userspace, but I'd suggest that you make it NOT dependent on Win32. It'd be much easier to implement features like fork (which Win32 doesn't support, but native processes do). Also, native process programming follows a lot of the same conventions that kernel programming does; the code would be more consistent and lightweight. Besides, it seems unlikely that FUSE would require Win32-specific features.
Please let me know if you get a source repository up.
Sure, people SHOULD be able to distinguish between Microsoft OS applications and third party ones, but there are lots of users who think everything on the computer is "Microsoft". I've come across those people before, and it's not pretty.
Supposedly, Microsoft does in fact send those crash reports back to ISVs and they sometimes fix their products because of it. They could definitely make that dialog clearer as to what happened and who is at fault, though.
The functions on that site are indeed largely undocumented (many of the functions are officially documented as part of the DDK, but only for use in kernel mode). The functions are considered private to the OS. No one is accusing Office or other Microsoft non-OS products from using those functions. They are only used to implement the Win32 API and some system services. I, too wish that they would document those since they are considerably cleaner and more stable interfaces than the Win32 equivalents, but please don't confuse private parts of the OS with special functions for MS applications. It'd be very infeasible for them to remove any of those functions; they're used heavily inside the OS to get things done. Never has a working function in the native API been removed or seriously changed. It'd be like removing the mmap() syscall from the Linux kernel in response to the mmap() vuln they had a while ago.
That's like saying that whenever one uses a function, one always winds up combining it with arguments: therefore function pointers are useless alone, they should always be bound with arguments when created. A pointer-to-member provides one more level of indirection than a delegate by making the target object a parameter. This parameter can be bound with an auxiliary class. C++ provides the support to make such classes behave very much like first class types.
I've found them useful for providing access to a private field or function of my choosing to a second class that will use it on multiple objects, i.e. an alternative to friend. The best part is that the target class can dispense different member pointers to provide different functionality, without modifying the calling class. An object can bottle an operation to be executed on an entire list of its peers, executed by a third party that needn't be privy to that operation.
A simple pointer to member is bound to the class type. However, any good C++ delegate class will not make the target class a part of its type: every compiler provides a way store a generic pointer to member, regardless of which class its a member of. As long as the delegate class guarantees that the class type and member pointer types match at runtime, it can safely cast to a generic pointer to member type. Users of the delegate class needn't worry about the details. The only remaining type information is the function signature.
Any good delegate implementation will support static functions. It would be nice to have directly nested functions, but you can still have functions nested in classes nested in functions.
The only function I can think of overloading on a delegate class is the parenthesis operator to make invocation pretty. If comparison would be useful, the default binary comparison operator would be sufficient. I once created a Sink class that implements single argument delegates in 48 text lines. It only overloads operator (). I wouldn't call that complex. And it isn't hard to use:
Granted, functions with variable arguments will require more work on the part of the library writer, but as a user of the class you don't have to worry about that.
Complexity isn't the same thing as implementing things in the core language that could be done in a library. Besides, there are definitely other language specs massive in size compared to C++'s: for example, Common LISP's specification is quite massive (about 1300 pages; there's a joke that Scheme LISP's entire language spec fits inside just the INDEX to index to Guy Steele's "Common Lisp: the Language, 2nd Edition"), and Perl certa
Right to begin with? What's wrong with C++'s implementation?
Pointers to members are useful in their own right. A pointer to member plus a pointer to the base object provides all the functionality of function and field delegates. One of C++'s greatest strengths is that the base language isn't weighted down by functionality that can be implemented in libraries, e.g. text strings. The less redundant pieces that go into a language, the better: libraries are much better for multiple alternatives.
Ok, how big are your registry hives really? The machine's hives are the extensionless files in %SYSTEMROOT%\System32\config. Your user's registry hive is in your profile: %USERPROFILE%. I really don't think that installing a new piece of software will contribute megabytes to the registry's size.
Furthermore, the registry has never used non-paged memory to load its hives, and since XP mounted hives are only loaded in 64k pages as needed.
COM has opaque random binary keys to identify components. Whatever database stores information for COM will have to include those keys, be it in a text or registry format. Besides, a text file for each program to read in its entirety to lookup a handful of relevant components in a linear search would be incredibly slow. The registry maintains B- trees for fast lookup. You can only maintain indexes in a binary database. Yes, some apps aren't terribly friendly to hand-editing. Some are. Regedit lets you enter numbers in hex, which is pretty good with bitfields. Most Microsoft entries that store config are readily hand editable. It all depends on the person who decided the format their app uses in the registry: they can choose to be friendly to manual editing or not. It's the same way for text files. I will say that UNIX has a generally better tradition of hand-edit friendly config files. Guess what: most users never want to see the inside of a config file or registry key. If there are options, there should be a friendly dialog box associated with it, with help, tooltips, validation, dynamic lists of choices and all the other nice things that only work in an interactive interface.
If the registry was really meant for computers only, there'd be no text strings naming keys and values. EVERYTHING would be referenced in GUIDs and private enumerations. Text is only necessary for interaction with humans. The registry is meant for both programs and power users to interact with. The filesystem's design is very similar. In fact, you could say that the registry is a highly specialized filesystem for use with a very large quantity of directories and files with with tiny values.
Most of the other restrictions you mentioned can also be accomplished with the built-in group policies.
Ok, upon actually reading the articles, my first paragraph is off: although the display part of MessageBox() is implemented entirely in the client side library, it may ask CSRSS to display the box instead. It's CSR that's mishandling that request in some weird circumstances. This isn't the only long standing bug of its kind in CSR. I sorta get the impression that no one at Microsoft really wants to touch the old CSR code (and may not even be competent to). The thing about "\??\" sounds like some debugging or obsolete piece of code that was written once and never read again. This is possibly a good case study for something that open source onlookers would've noticed as a bogus special case while browsing code.
My point about how apps should sanitize data from untrusted sources before passing it to internal library functions still stands, though... just not as much in this case.
For one thing, MessageBox() is implemented entirely in user32.dll, a client library which runs directly in the client process calling the function. CSRSS and win32k only implement lower level primitives like windows and display contexts (Here's a list of both the service tables; scroll down to win32k.sys to see all of it's functions). MessageBox() uses those to create a new window with the specified buttons and text on the fly with those primitives; the vulnerability is inside that code. There's no reason to put MessageBox() on the server side (i.e. in CSRSS or win32k). MessageBox() is not a path to privilege escalation.
However, this still could be a vulnerability if any programs pass arbitrary user data directly to MessageBox(). This seems to be like the GDI+ vulnerability: another client side library that wasn't prepared to deal with bad data coming from another module within the same process. The problem is that that bad data may have originated from outside the process, being passed on to the library verbatim. Shared libraries don't usually check their interfaces for security heavily because they weren't expecting to be handling data from the outside world-- only data coming from within the process.
The convention always was that the onus for providing correct data to a library was on the caller. If the data is bad, the only process that is hurt is the one that provided the bad data-- no escalation because a process can only hurt itself. The idea was that since only external interfaces are connected to untrusted sources like the outside world, only external interfaces need rigorous checks. Traditionally, library functions were used only as internal interfaces. As programs become increasingly abstracted, they pass their data more directly to their libraries. The problem occurs when a library trusts the calling application to validate data, when the application thought the library was going to do it.
Another thing this is similar to are SQL injection vulnerabilities. When SQL was created, only operators and services trusted to some extent by the system could write queries. When the line between data and query was blurred with various forms of dynamically generated queries, poorly written front-ends allowed user data to bleed directly into the SQL statements that (used to be) trusted.
As with SQL injection, I'd say that the onus should still be on the caller to provide sanitized data to naive functions like MessageBox(). It doesn't matter that MessageBox() will do bad things if it gets bad data; any program that talks to untrusted sources should sanitize incoming data BEFORE it gets to such functions. Javascript allows you to pop up a message box, but it's the browser's job (since it's the one talking to the outside source) to make sure that the text in the box is clean before passing it on.
As long as front-end program code doesn't prematurely abdicate it's responsibility to sanitize incoming data, vulnerabilities like this one and the GDI+ one won't be an issue. The only time they can pass that responsibility on is when the library states that it can accept it, either explicitly or implicitly by being an external interface (like a network service).
Even if we don't have free will, our actions still have causes in the real world; people's actions can still be affected by laws and potential punishment even without free will. Someone who thinks of killing another for the sake of jealousy will still consider the consequences of that act imposed by the state.
Besides prevention of crime, laws are useful to denounce certain activities as not condusive to a stable, productive society. Even without free will, it'd be useful to figure out what things would tend to damage society (along with the things and people in it), make a list of them and their severity and advertise it.
Even without free will, rehabilitation is possible. Some people's destructive behaviors can be fixed enough so that they can be let back into society. Actually, free will could make rehabilitation more difficult because it implies that there is a part of a person's nature that cannot be modified. I'm not suggesting that people be brainwashed (because it's too easy to abuse), but rehabilitation is easier in theory if people's behaviors are more deterministic.
As for retribution, i.e. revenge, how is that helpful? How does it specifically help someone (or society) to accomplish revenge?
In any case, good post.
Scott Adams (writer of Dilbert) has had some interesting posts on (the lack of) free will on his blog.
Windows NT 3.1 was released in 1993. It had fully protected memory, strict user/kernel separation (i.e. only the kernel can touch hardware devices), and fully preemptive multitasking (even for threads running in kernel mode). Windows NT 3.1 marked the first implementation of Win32. NT wasn't marketed as a consumer OS until version 5.1 (XP) in late 2001, but NT 3.1 was offered as a general purpose OS with plenty of overlap with DOS/Windows 3.1. It could run many Win16 and DOS programs, as long as they used Windows, DOS and BIOS interfaces to access hardware (as opposed to 9x which usually didn't care).
Here are the worst things I can think of a bad uninstaller leaving:
- Files are left over in system directories (e.g. %SystemRoot%\System32) that aren't used anymore. NTFS uses B+ trees to index directory entries. You'd have to at least double the number of entries to cause a noticeable slowdown. The leftover files will waste space, but they'd have to be hundreds of megabytes to impact system performance.
- Keys are left over in the registry. The registry uses B-trees to index key and registry data. The HKCR tree alone contains about 94 thousand keys and 34 thousand values in a fresh XP install. There would have to be at least an increase of that magnitude to impact performance.
- References are left to non-existent shell extensions and startup items. It'll only take Explorer one failed call to CreateProcess or LoadLibrary to figure out that the items are broken. From those functions, the OS would only have to perform a few failed file lookups to realize the files are non-existent. Fixing this kind of thing is easy with autoruns.
- Broken COM references. Like other leftover registry keys above, there'd have to be an awful lot to cause slowdown. The only time I can think of that a program would actually list all of the COM components is when an IDE like Visual Studio is giving you a list of available components. In all other cases, a program will already know what its looking for and be unaffected by unrelated entries.
If there actually is some source of inevitable slowdown after a Windows installation has seen use, there has to be a cause. If no one can tell what that cause is, you'll understand if people like the parent and I call bullshit on such claims.I knew about the forcedeth driver, but my statement that it wasn't ready is definitely out of date. All I can say is that it wasn't ready back when I was building the machine. I can't figure out if it's out of the "experimental" state yet though (not that it matters; I'd use it now). Thanks for the update.
Microsoft writes lots of drivers. They have drivers for all sorts of standardized hardware with open specs, like OCHI USB controllers. What Microsoft doesn't (and can't short of reverse engineering) write drivers for are pieces of proprietary hardware. The same reason that the only good Linux nVidia video drivers are a binary from nVidia is the reason that Microsoft doesn't write nVidia's video driver either.
Of the 118 driver modules currently loaded on my system, 100 of them are (C) Microsoft Corporation. The others are 5 for VMWare, 2 for my nVidia video card, 1 for the nVidia nForce MCP net adapter, 1 for the Realtek 650 sound, 1 for the OpenVPN virtual TAP adapter, 1 for the crappy Macromedia safedisc copyprotection driver, 2 for Daemon Tools, 1 for Process Explorer, and 4 for the cd burning software. Of the non-Microsoft drivers that are supporting real hardware, that's 4 drivers for 3 devices. There are only three devices on my system that Microsoft didn't write drivers for. If Linux were running on this system, I'd want the binary nVidia drivers for video and networking (AFAIK nForce2 networking still isn't supported in the mainline. It definitely wasn't when I built the machine).
Microsoft definitely has a drivers division.
I do agree about Microsoft fixing the wrong things most of the time in their OS, though.
While I can switch insurance companies in a month, tops, politicians are only held accountable at election time, if you're lucky. People have to actually be aware of the issue, at election time, and not be blinded by hot-button issues or mindlessly fill in their lifelong party bubble on the ballot. Capitalism puts the choice for my care directly in my own hands; I don't have to depend on the whims of the majority. Most elections are about 1-3 hot-button issues. Gross inefficency has never been one of them, AFAIK. Look at the US's national debt: a corporation would've been bankrupt long ago, but the government can print money and borrow way past its means. Where's its accountability for that? That's a problem with the employers making the choice for you. By itself, it's no different than the state making the choice for you. Either way, the choice is made by someone "above" you. You can always buy supplemental insurance if you want...
There are A LOT of health plans available. I'd be very surprised if you were unable to find one that suits you. There are so many, the overhead of interfacing with them generically is causing an excessively huge overhead, a conclusion I share with your sources.
The OP knows exactly how much he's paying for healthcare. You don't.
The OP has a choice about which coverage option to choose, and can change if it's not the best option given individual circumstances. You don't and can't.
Things don't come for free. It's all about how you choose to pay for it. Personally, I'd much rather have the choice in my own hands, rather than in the hands of a politician who can't possibly know what's best for me as an individual, and has only weak standards of efficiency to live up to.
From what you're saying, Costco is more profitable than Sam's Club because Costco's management understands the value of employees in the long term, while Sam's Club's management doesn't. This is an issue of management competence, not "Liberal" vs "Republican". Both companies are interested in making money, it's just that Costco is better at it because they better understand what's valuable in the long term.
Since Costco management understands the real value of its employees and customers, Costco receives many rewards, including lower employee turnover, better customer loyalty and higher total profits. Sam's club management doesn't understand, and so are doing poorly. This is capitalism at its best: competence being rewarded.
There's no conflict between long term profits and making the world a better place. People have value. Those who understand that will be more profitable.
NTBackup used to let you back up your own files, or any other files you have read access to. Last I checked, Vista Backup won't run at all unless you are an administrator. I say "used to" because the NTBackup version with Volume Shadow Copy support (from WS2003) isn't included with and won't run on Vista.