To quote from my post, "If you're just going to compare with VC6, which is a decade old next month, I'm not interested."
In fact, given that you are quoting from the October 1997 issue, you're comparing against an even older compiler.
Surely you must have something that's slightly more current to support your claim?
At the very least, post the source code....
I have no idea what you're talking about, I'm afraid.
If the Delphi compiler is so awesome, why not give us a comparison of a program doing the same computation in the same way written in both Delphi and another language (C++, say), built using modern compilers? If you're just going to compare with VC6, which is a decade old next month, I'm not interested.
So? Apple keeps adding new features to its C-based APIs as well.
Apple isn't claiming otherwise, though, whereas posters here are claiming that people shouldn't be using Win32 at all, but instead using.NET.
AFAIK, Apple has never pretended that Cocoa is complete; that you use e.g. BSD sockets is promoted as a virtue, not a flaw.
To make it clear: my objection is to people claiming that criticism of Win32 is in some sense "invalid" because I "should" be using.NET. If I "should" be using.NET then MS has got to stop adding features to Win32 and make.NET a complete replacement. Until that happens, criticism of Win32 is fair game.
How exactly does it make you care which thread runs the message pump? The only thing you need to know is that unless you do otherwise, your code is on the UI thread and so you shouldn't block it.
Have you read the documentation for the Control object?
Specifically InvokeRequired and IsHandleCreated?
Have you read the sample code for the control that spins off a thread?
Ok, go and read those, then we can consider a little scenario: a control that spins off threads to do some work in the background, and then update the UI when it's done.
Let's imagine that our control doesn't bother checking IsHandleCreated, and that it just creates its thread indiscriminately. The UI update does call InvokeRequired but--as we know from the docs--InvokeRequired returns false when there's no handle at all.
Let's imagine also that (a) the background work completes quickly (b) our application hadn't created any window handles until before our thread started (this can happen, which is why the IsHandleCreated property even exists).
So the background work finishes. It tells the control to update its UI from the background thread. The control checks "Is InvokeRequired?". The answer is "no". So it tries to update the UI. But the window handle hasn't been created yet--nothing to update! And there's no message pump yet--nothing to dequeue messages anyway.
OK, so that's not ideal. But it gets even less ideal. What if your update code causes a handle to be created? There's a good chance that it will (even the mere act of requesting the Handle property will create the HWND if it doesn't yet exist). But because you're running in the background thread--no invoke was required, remember?--it'll create a handle (and message pump) in the background thread. Even better, any not-yet-created HWNDs in the rest of your UI that you try to modify will also use the background thread's message pump. Which means that when the background thread exits after making its update (it has no more work to do, after all) any other controls that it updated will no longer have a thread to handle their messages!
This is all needlessly complex and unnecessarily fragile.
So let me understand; they release the ribbon, decide to include it later, but you're going to fault them now because it's not built into the OS right now? Interesting.
No, not at all. You're being obtuse.
If.NET is the way forward, *why are they not adding the ribbon to.NET*? Why have they added one to MFC, and why are they adding one to Win32, but *nothing* for.NET? Do you not see the contradiction here?
"I see, so because your toy application needs to call into win32, that makes.net "really exteremly imcomplete." Nevermind the huge chunk that is there, that people are using to build compelete applications. Maybe you should complain to MS and tell them to drop everything to port it all to.net now, instead of pieces at a time."
I don't want them to "port" anything. I want good clean APIs, and a "port" of Win32 won't provide that.
ICollections implement an IEnumerator interface and have an Enumerator object which counts the objects in a collection. Think of an enumerator as an odometer (like the one in your car). If the object implements ICollection, then it has an odometer, which you can get the count from. Arrays just have size.
Count is not a method; it is not asking "Count how many things are in this object". It is a property, and as such an intrinsic feature of the object (that behind the scenes it might have to do the verb thing is beside the point--it's semantically a property, even if it's actually a verb).
And even if one were a verb--why should be it?
Again, difference between an attribute and a verb. LongLength is an attribute of an object, such as height or width. Whereas Count is like an odometer in your car. Your question is kind of like asking why can you travel tens of thousands of miles along the US highway, but my odometer in my car only goes up to 1000. Well, that's just the way the odometer was made. Length of trip is distance, whereas your odometer is a counter and is only a *measure* of distance. It's simply a distinction the language makes.
Again, though, the language doesn't make the distinction you are making. Count is a property, just like Length. If Count were a method I could sort of understand the difference (I don't really agree with it, it seems spurious, but I could sort of understand it). But it's not; it's a property.
Chunking..NET gets used on both 32 and 64 bit platforms, and the performance penalty for splitting a 64 bit word into two is greater than using two 32 bit words. In the first case, you still have to use 64 bit words, but you pad the first 32 bits with zeros, and convert to 32 bit words. Requires an extra pass through the processor to calculate, whereas adding two 32 bit words into a 64 bit word is trivial. I'm not explaining this concept well, but if you look it up you'll find more info on the question you're asking. The design decision was based on current market saturation of 32 bit processors, and the LongLength was an added conversion for the 64bit programmers.
But LongLength means we won't have a clean transition, because it means people will have to fix up APIs to take longs where they currently take ints; making everyone pay the price for longs might be a short-term cost (though not a great one), but it'll be a long-term gain.
Using the odometer analogy as above, the enumerator only goes forward; although you *can* reset it. If you want to do reverse iteration, copy your collection into a new collections backwards, and iterate over that new object. Alternatively, for most reverse or bidirectional iterations, you'll simply want to ditch the 'foreach' loops, and use a simple 'for' loop. Then you can start high and use decrement iterators to count down. I also like to use decrementor collections which get an object removed with each pass of the for loop.
That really doesn't answer the question. In both Java and C++ I have iterating objects (java.util.ListIterator, C++ bidi/random iterators) that can go forwards and backwards. I use these quite regularly; why can.NET not provide the same?
You need to get the IEnumerator object from the ICollection, using the GetEnumerator method. It will have a Position field.
But he didn't give any details of how win32 leaks into.Net. The threading model of the GUI is single threaded for a reason outside of Win32; multi-threaded guis are hard, and they don't buy you anything. Perhaps the article was a little unclear on this point.
The issue is not that WinForms is single-threaded.
It's that WinForms makes you give a damn about which thread runs the message pump.
Even the new UI Wpf has thread affinity. If you know this, its really easy to code against. The only problem was pre-.Net 2.0, which allowed you to make cross thread calls..Net 2 now does the proper thing, and throwns an exception. It's a pity it only does so in debug builds.
There are third party managed ribbon controls; Infragistics offers one. Also, with Wpf it's fairly simple to do your own ribbon style control. With WinForms you're better off using the Infragistics one. Why you think the ribbon should be a standard Windows control I'm not sure. I think it should be because MS thinks it should be. That's why it's been added to MFC, that's why it's being added to Windows Seven.
Well, I can't say I've need to use transactional NTFS yet, but otherwise I can do everything I need with just the framework. I'm curious, what kinds of things are you doing you need to use Win32 so much? My current "toy" application is a media player. Something in the same vein as Sasami2k. DirectShow is unusable from.NET (it's a COM interface, with no primary interop assembly and a bunch of hairy bits that make interop difficult). The brand spanking new-to-Vista Media Foundation (which will eventually replace DirectShow) is also COM (and again with no PIA)..NET is really extremely incomplete as a Win32 replacement.
TxNTFS isn't WinFS. TxNTFS is a set of features built on the same underlying filesystem; WinFS would be a separate data store (probably stored on an NTFS volume, but with its own internal structure).
The article didn't actually describe any accurate parts of Win32 that leak into.NET, except that WinForms is based on the WinProc event model of GUI development. That's one of the many valid ways to implement GUIs, and there's no reasoning as to why this isn't a valid design decision for Microsoft to make.
Well, there is a good reason why it's not valid: because it makes.NET developers give a damn about HWNDs, message pumps, and the interactions between the two.
Other than that, he points out a bunch of flaws in Win32 and implies that they "leak into.NET" but he fails to actually demonstrate any of them.
Off the top of my head we have, for example:
the entire crypto lib (including e.g. certificate handling as well as core crypto functions)
SSL handling equally has Windows-specific portions
SocketException (especially ErrorCode)
Socket.UseOverlappedIO
Socket.IOControl
System.ServiceProcess.* (this stuff should be in Microsoft.whatever, not System!)
System.Management.* (ditto)
System.Data.SqlClient.*, System.Data.OracleClient.* ((a) the core interfaces should be better (b) the vendor-specific providers should not be in System)
The "Handle" properties found in e.g. Socket, FileStream, and the aforementioned System.Windows.Forms
Large tracts of System.EnterpriseServices
Win32isms are abundant.
Further, your arguments that somehow cutting edge enhancements like Vista's new TxNTFS should magically appear in.NET by now make no sense to me.
Let's just recap the argument, shall we?
1) Claim: Win32 is clunky and horrible
2) Response: Write in.NET
3) Claim:.NET can't do everything Win32 can do, forcing me to use Win32
4) Response: "your arguments [...] make no sense to me"
Look, if the argument is going to be "Don't use Win32, use.NET" then.NET has to do all the things that Win32 can do. So which is it?
Either I should be using.NET--in which case MS's failure to add new Win32 features to.NET is a problem--or I should be using Win32--in which case "use.NET" is not a suitable response to cited flaws with Win32. You can't have it both ways, so which is it to be?
<quote>Name a feature of C++ templates (other than multiple inheritence) that cannot be done in.NET with generics. I really tried to think of one, but I couldn't come up with a meaningful example.</quote> Then you're really not thinking very hard; apart from some slight syntactic similarity,.NET generics are a totally different beast to C++ templates (both have their virtues, and both are useful, but they do very different things). Here's something I'd like to be able to do in.NET; something that's trivial with templates (this code is only a rough approximation as I don't have a compiler to run it through, but it's enough to give you the idea):
template<typename T> struct complex { T real; T imaginary;
I agree. It sounds to me like this guy used.NET for a year or so around 2002 when it was brand new and then left and hasn't looked again for the last six (6) years. He is the first person that I have heard accuse.NET of being "too simplistic". The.NET class library (and Java class library as well) is the definition of everything and the kitchen sink. These are extremly powerful languages and libraries that are if anything too complex.
You seem to be confused between broad (.NET supports a lot of things, like sockets and cryptography and distributed transactions and GUIs and XML and oh my!) and powerful.
.NET does a lot of different things, but.NET doesn't have the greatest underlying abstractions. For example, to name a few:
IList requires integer indexing. This makes it unsuitable for some kinds of sequential collection such as linked lists, which have no acceptable way of implementing integer indexing. Consequence? IList, whose documentation proudly claims to be "the base interface of all generic lists" is not, in fact, "the base interface of all generic lists". LinkedList does not implement IList.
IList has no ToArray, but List does. Sure, ICollection has Count/CopyTo, but if the convenience method is good enough for List, it's good enough for IList. OTOH, if the convenience method is unnecessary for IList, it's unnecessary for List.
Except for to confuse me, why do ICollections have a Count, when arrays have a Length? What's the meaningful semantic distinction that I'm missing here?
Why do arrays have LongLength but with no corresponding LongCount for ICollections (3.5 adds LongCount as an extension method, but that gives it inconsistent (method) syntax, and of course it can never work because even if the collection were extended to support long lengths, an extension method can never exploit that fact, because the extension just works on IEnumerable which supports only an int Count)?
Why do arrays have LongLength, and not simply have Length be a long? It surely didn't take a whole lot of foresight to figure that one out, did it?
Where do I find reverse iteration/enumeration?
Where do I find bidirectional iteration/enumeration?
Why does the LinkedList expose implementation details such as LinkedListNode to users?
Why is there no generalized mechanism for storing my position in a container?
Why does HashSet have no ISet interface?
Why is there no SortedSet?
Why is System.Collections.ObjectModel not System.Collections.Generic.ObjectModel given that it is, in fact, for generic collections?)
Why are there no static type-inferencing factories for read-only collections or singleton collections? When you have generics, factory methods are good, because factory methods can infer. Don't make me type IList myReadOnlyList = new ReadOnlyCollection(myList); the double specification of the type is spurious.
Why is it named ReadOnlyCollection when it is in fact a IList?
Why is there no true ReadOnlyCollection (i.e. that is actually useful for collections)?
Why is it named SynchronizedCollection when it is in fact an IList?
Why is there no true SynchronizedCollection (i.e. that is actually useful for collections)?
Why is there no deque class?
Why is there no IStack?
Why is there no IQueue?
Why do Stack and Queue hardcode their backing store, even though the performance profile may be better off using e.g. a linked list, deque?
Why is KeyedByTypeCollection so widely useful as to even exist?
Where do I find an equivalent to java.util.concurrent? Anyone suggesting SynchronizedCollection, please punch yourself in the face right now.
Why are there new (.NET 2.0) classes that use old (non-generic) types, e.g. System.Net.Mail.MailMessage.Headers, which uses NameValueCo
Sure, the.net framework may be calling Win32 under the hood right now, but there's no reason to believe that that can't be swapped out for Something Completely Different (tm). Really?
So you think that swapping out (let's say) the networking stack for something that doesn't use Winsock error codes will not break code?
How about swapping out the WinForms implementation for something that doesn't use HWNDs and doesn't send window messages in the same order?
Or implementing a crypto lib that doesn't call Win32's CryptoAPI or CryptoNG?
Yes, you could probably do it, but doing it in such a way that doesn't break anything is going to be a struggle, don't you think?
It's pretty clear from the design that.NET isn't actually designed to be all that cross-platform; MS has been quite happy to put thin wrappers around Win32 in various places, which severely constrains other implementations.
Personally, I don't actually mind that it's not especially cross-platform; it makes little practical difference to anything most people write. I do wish they hadn't billed it as being cross-platform in the first place, though; it just makes them look stupid.
What is more upsetting is that the platform it's tied to is so skanky.
No, he is saying that the argument is confused because it mixes up Win32 and.NET. That's a problem with TFA. But the article doesn't do that, except when describing how details of Win32 leak into.NET.
If you want to compare Windows and OS X as modern platforms, you need to compare the modern APIs, that is,.NET against Cocoa, nothing else. But you can't. MS has added new features to Win32 (and VC++/MFC), and MS is going to continue to do so in Windows Seven. For example, Vista has a new transacted (database-style ACID transactions, not just journalled) filesystem..NET doesn't support it; you've got to use Win32 to use it. Even though.NET does have transaction support (for COM+ transactions and database transactions) it doesn't support TxNTFS. So you've gotta use Win32. Or how about an MS-supported ribbon control? You've got to use MFC, and in Windows Seven there should be a native code ribbon control as part of the OS proper. In both cases, no managed code.
Having to drop into Win32 to call some legacy thing that no-one should really be doing but which you have to do for backwards compatibility, that I could sort of understand. But having to drop into Win32 to call new features that have only just been added? Anyone saying "stop using Win32, just use.NET" doesn't know what they're talking about.
There are vaccinations for rabies, and prophylactics that should prevent someone exposed to the virus from developing it, but no cures. Only a handful of people have survived after developing symptoms.
That's pretty perverse. You can live years/decades with HIV with effectively no ill effect; rabies is pretty much an immediate death sentence. The number of people surviving more than a week or two is about two or three.
WPF applications are D3D scenes, yes. But they get rendered to flat surfaces (and additionally, there's AFAIK no way to get at the underlying D3D primitves; WPF is D3D accelerated, but all the D3Dness is abstracted away).
GDI applications similarly get rendered (in software, no GDI hardware acceleration with WDDM) to surfaces.
But that's not what I'm interested in. I'm not talking about the stuff within each window (though even if I were, your comment about WPF makes no sense, because most windows are GDI windows, not WPF).
DWM creates a hundred-odd triangles for each window, and uses the aforementioned surfaces to texture each windows. But there's no programmatic access to those triangles or the surfaces or textures. The D3D scene that represents "the desktop" (and all the windows within it) is inaccessible.
Or to turn it on its head: which API call do I make to get a IDirect3DVertexBuffer9 and IDirect3DTexture9 for an arbitrary window on the desktop? If I can get to the D3D scenes, I can get to them, right? How?
"but the important thing is that the API is now there for anyone to harness"
No it isn't. It's one of the things I touched on in the article (and I plan to write more on the subject).
The only thing we get (as developers) is thumbnails. We have no access to the D3D scene (i.e. the triangles and textures that make up each scene). Thumbnails don't cut the mustard. You can't do enough stuff with them.
OS X doesn't expose an API for that either (it's an OpenGL scene, but still triangles and textures), but Apple have at least done some reasonably sensible things with the facility--Exposé being the big one, but other stuff (like the ripples when you add a new gadget to dashboard) are nice too. Beryl does some interesting (not necessarily useful, but fun) stuff too--effects like the exploding windows really ought to be integrated into the scene (making more textured triangles and then animating them to "explode").
I could sorta live with DWM's lack of API if MS were at least doing cool stuff themselves. But they're not; they're just doing Flip3D. Which is, as mentioned, pointless.
It's extremely disappointing. MS have actually surpassed Apple's technology in many ways (MS are the first to have a stable, composited, 3D-accelerated desktop *with 3D-accelerated drawing primitives*--Apple don't have the latter because they can't get QuartzGL working, and Beryl/compiz/Cairo/etc. do not IMHO yet deserve the "stable" moniker--and as a practical issue, I'm sorry, but it's Apple who are the benchmark here, not the open source people, from a sheer practicality standpoint). But MS have done so much less with it than Apple. They've really missed a big opportunity, IMO. Rather than capitalizing on that advantage, they've squandered it. I think a similar complaint could be levelled at Apple (QuartzGL *still* isn't working?), but I think they've done much more with the capabilities their software has than MS. They're far better at using their latest and greatest technology, even to the extent of building whole new applications around it (e.g. Aperture and Core Image).
"As for entering a password vs. clicking a button - sudo on Mac OS and Ubuntu Linux (and probably any other sane configuration of sudo out there) ask for the password and then cache it for while so you can perform a series of admin tasks. That is intelligent." Well, no, it isn't, because malware will attack it; OS X has already had vulnerabilities relating to this very thing (applications could detect when privileges have been raised and silently perform privileged operations in the background).
"Or I can use sudo to get a root shell or on some configurations su to root for what I need." Much like how in Vista you can create an elevated command-prompt/Explorer/etc. that doesn't need to prompt, you mean?
"The models you are discussing are pretty much limited to information flows, and generally apply to the file space (including in-memory equivalents.)" OK, now I see where you're coming from (though in NT they've always applied to much more than the file space).
"In this respect, the "unix based model" I'm referring to is exactly 2 levels of privilege: normal user and superuser. VMS finer grained privileges allowed a user (or more accurately a process operating on behalf of a user) to get selected privileges to do specific things. Some that I remember (from way long ago) were: Start/Stop printer queues, Exceed Disk Storage Quotas, Change File Ownership/Permissions, Change Scheduling Parameters (i.e. process priority), lock pages into virtual memory (a favorite for tuning applicatins) and my favorite, Set Process Privileges (basically this was the meta-privilege, it was the privilege that allowed you to enable to disable other privileges...)" Ok, yes. NT has a similar set of privileges, that are generally orthogonal to the DAC permission system. For example, there's a privilege for "change process priority", one for "lock pages into physical memory", and a bunch of others. These are all actively used and enforced, although you might not notice as the privileges are available to Administrators by default anyway (though even when available they must be programmatically enabled).
"p.s. In the file space itself, VMS had a 4th permission bit, that prevented you from deleting the file. I still remember RWED as the order of the permissions (and I stopped using VMS in about 1984...) It turns out to be quite handy to say to a user "You can read/write this file, but you can't delete it." When you couple that with VMS file versioning, that provided a lot of help against accidental deletion of files by both fat-fingered users and inadvertently misbehaving software." It's funny you should mention that; one of the rationales for the Biba integrity model is that writing is functionally equivalent to deleting anyway.
What the hell is a "unix-based security model"? A model is something like "discretionary access control" or "mandatory access control" or "role-based access control, etc.. Traditional unix (POSIX user/group/world permission bits) are DAC. So are POSIX ACLs. So are Windows NT ACLs. So is VMS. The conceptual basis behind all of these things is the same. The granularity and expressiveness may vary (ACLs are more expressive and finer-grained than permission bits), but the models are identical. Only the implementations differ.
MAC (essentially, labelling) is rarer, but is found in "Trusted" OS variants, and I think is an option in e.g. SELinux. Vista also incorporates some elements of MAC; MAC can provide one of two things; confidentiality (Bell-LaPadua) and integrity (Biba) (though they're contradictory; the restrictions that guarantee integrity violate confidentiality, and vice versa). Vista's MAC is there to provide integrity.
They don't do it because typing a password is too damn annoying.
UAC is still useful as an Administrator. Until you elevate your privileges, a UAC user *is* a regular user (essentially they have two possible tokens, a regular user token and an Administrator token, and unless you elevate, they're using on the regular user token). This means that the "protection" that it offers is the same; what differs is the ease with which you can switch between the two kinds of user (click a button vs. enter a password). So I don't think that's actually a huge problem.
Whenever something is done for which the regular user token isn't good enough, you can elevate to an Administrator token. That brings up the UAC prompt; it does it for broadly the same category of operations that MacOS X or Linux will demand root access for.
The thing is, the prompt is quite annoying. It's not any more annoying than it is on other OSes; they're annoying too. But a password is even more annoying than clicking the box. And if something is annoying, well, people are going to try to avoid it.
That's the dilemma faced by MS. If they make the thing too annoying, everyone will one way or another disable it. Originally UAC not only required a password, but also a ctrl-alt-del (so that the password couldn't be intercepted or anything). ctrl-alt-del to enter the password was too annoying; it was too intrusive. So they disabled that by default (though you can reinstate it if you want, through a GPO). Entering a password by default was also too intrusive, so again, they disabled it by default (and again, you can reinstate it across the board, even for Administrators, if you want). The reason they did this is because they want the level of annoyance to be livable. If UAC is so annoying that people outright disable it, it's useless. If it's a minor annoyance, they probably won't turn it off.
I've been using Vista since it went RTM, and I have to say, I don't see many UAC prompts any more. I did at first, when I was installing all my software, but now, it's pretty infrequent. It's certainly something I can live with. I did try cranking it right up--passwords for all users, with ctrl-alt-del to enter them--but it's far too annoying to put up with. I can't really fault MS for making the trade-off the way they made it. Hopefully, as applications improve, elevation prompts will become more infrequent (for example, I have to elevate to play Battlefield 2, because Punkbuster "needs" admin rights... this is something that they really need to fix), and when this happens, demanding a password to elevate won't be so onerous. But as things stand right now, there are just too many problematic applications. This isn't really MS's fault (it's not like NT's DAC is new...), but it is something that they've got to live with, and provide a solution for.
The theoretical underpinnings of the Windows security model are DAC, with limited MAC (specifically, the Biba Integrity Model). The MAC stuff is new to Vista; the DAC stuff has always been in NT.
The DAC model is the same as that found on typical Linux, Solaris, AIX, Mac OS X, FreeBSD, etc. installations. The Biba model is rarer (but nonetheless theoretically sound), but it's rumoured that Leopard will use it too.
In other words, shut the fuck up; you don't know what you're talking about. But I guess that's to be expected of anonymous cowards when talking about Windows.
Slashdot Mirror
Your understanding has no basis in reality. Both traditional DirectShow and new Media Foundation codecs can be--and are--shared.
The noble gas is xenon, not Xeon.
To quote from my post, "If you're just going to compare with VC6, which is a decade old next month, I'm not interested." In fact, given that you are quoting from the October 1997 issue, you're comparing against an even older compiler. Surely you must have something that's slightly more current to support your claim? At the very least, post the source code....
I have no idea what you're talking about, I'm afraid. If the Delphi compiler is so awesome, why not give us a comparison of a program doing the same computation in the same way written in both Delphi and another language (C++, say), built using modern compilers? If you're just going to compare with VC6, which is a decade old next month, I'm not interested.
I bet you couldn't even write a program that would score 5/5 at ZDNet.
Apple isn't claiming otherwise, though, whereas posters here are claiming that people shouldn't be using Win32 at all, but instead using .NET.
AFAIK, Apple has never pretended that Cocoa is complete; that you use e.g. BSD sockets is promoted as a virtue, not a flaw.
To make it clear: my objection is to people claiming that criticism of Win32 is in some sense "invalid" because I "should" be using .NET. If I "should" be using .NET then MS has got to stop adding features to Win32 and make .NET a complete replacement. Until that happens, criticism of Win32 is fair game.
Have you read the documentation for the Control object?
Specifically InvokeRequired and IsHandleCreated?
Have you read the sample code for the control that spins off a thread?
Ok, go and read those, then we can consider a little scenario: a control that spins off threads to do some work in the background, and then update the UI when it's done.
Let's imagine that our control doesn't bother checking IsHandleCreated, and that it just creates its thread indiscriminately. The UI update does call InvokeRequired but--as we know from the docs--InvokeRequired returns false when there's no handle at all.
Let's imagine also that (a) the background work completes quickly (b) our application hadn't created any window handles until before our thread started (this can happen, which is why the IsHandleCreated property even exists).
So the background work finishes. It tells the control to update its UI from the background thread. The control checks "Is InvokeRequired?". The answer is "no". So it tries to update the UI. But the window handle hasn't been created yet--nothing to update! And there's no message pump yet--nothing to dequeue messages anyway.
OK, so that's not ideal. But it gets even less ideal. What if your update code causes a handle to be created? There's a good chance that it will (even the mere act of requesting the Handle property will create the HWND if it doesn't yet exist). But because you're running in the background thread--no invoke was required, remember?--it'll create a handle (and message pump) in the background thread. Even better, any not-yet-created HWNDs in the rest of your UI that you try to modify will also use the background thread's message pump. Which means that when the background thread exits after making its update (it has no more work to do, after all) any other controls that it updated will no longer have a thread to handle their messages!
This is all needlessly complex and unnecessarily fragile.
So let me understand; they release the ribbon, decide to include it later, but you're going to fault them now because it's not built into the OS right now? Interesting.No, not at all. You're being obtuse.
If .NET is the way forward, *why are they not adding the ribbon to .NET*? Why have they added one to MFC, and why are they adding one to Win32, but *nothing* for .NET? Do you not see the contradiction here?
"I see, so because your toy application needs to call into win32, that makes .net "really exteremly imcomplete." Nevermind the huge chunk that is there, that people are using to build compelete applications. Maybe you should complain to MS and tell them to drop everything to port it all to .net now, instead of pieces at a time."
I don't want them to "port" anything. I want good clean APIs, and a "port" of Win32 won't provide that.
ICollections implement an IEnumerator interface and have an Enumerator object which counts the objects in a collection. Think of an enumerator as an odometer (like the one in your car). If the object implements ICollection, then it has an odometer, which you can get the count from. Arrays just have size.
Count is not a method; it is not asking "Count how many things are in this object". It is a property, and as such an intrinsic feature of the object (that behind the scenes it might have to do the verb thing is beside the point--it's semantically a property, even if it's actually a verb). And even if one were a verb--why should be it?
Again, difference between an attribute and a verb. LongLength is an attribute of an object, such as height or width. Whereas Count is like an odometer in your car. Your question is kind of like asking why can you travel tens of thousands of miles along the US highway, but my odometer in my car only goes up to 1000. Well, that's just the way the odometer was made. Length of trip is distance, whereas your odometer is a counter and is only a *measure* of distance. It's simply a distinction the language makes.
Again, though, the language doesn't make the distinction you are making. Count is a property, just like Length. If Count were a method I could sort of understand the difference (I don't really agree with it, it seems spurious, but I could sort of understand it). But it's not; it's a property.
Chunking. .NET gets used on both 32 and 64 bit platforms, and the performance penalty for splitting a 64 bit word into two is greater than using two 32 bit words. In the first case, you still have to use 64 bit words, but you pad the first 32 bits with zeros, and convert to 32 bit words. Requires an extra pass through the processor to calculate, whereas adding two 32 bit words into a 64 bit word is trivial. I'm not explaining this concept well, but if you look it up you'll find more info on the question you're asking. The design decision was based on current market saturation of 32 bit processors, and the LongLength was an added conversion for the 64bit programmers.
But LongLength means we won't have a clean transition, because it means people will have to fix up APIs to take longs where they currently take ints; making everyone pay the price for longs might be a short-term cost (though not a great one), but it'll be a long-term gain.
Using the odometer analogy as above, the enumerator only goes forward; although you *can* reset it. If you want to do reverse iteration, copy your collection into a new collections backwards, and iterate over that new object. Alternatively, for most reverse or bidirectional iterations, you'll simply want to ditch the 'foreach' loops, and use a simple 'for' loop. Then you can start high and use decrement iterators to count down. I also like to use decrementor collections which get an object removed with each pass of the for loop.
That really doesn't answer the question. In both Java and C++ I have iterating objects (java.util.ListIterator, C++ bidi/random iterators) that can go forwards and backwards. I use these quite regularly; why can .NET not provide the same?
You need to get the IEnumerator object from the ICollection, using the GetEnumerator method. It will have a Position field.
Neither here: http://msdn.microsoft.com/en-us/library/system.collections.ienumerator.aspx Nor here: http://msdn.microsoft.com/en-us/library/78dfe2yb.aspx So I'm not altogether sure what you mean.
Probably implemented somewhere else.
I don't understand what you mean.
You're splitting hairs here. It's a strongly typed language. It's meant to be explicit, not inferential. In other projects, besides yours, do
TxNTFS isn't WinFS. TxNTFS is a set of features built on the same underlying filesystem; WinFS would be a separate data store (probably stored on an NTFS volume, but with its own internal structure).
Well, there is a good reason why it's not valid: because it makes .NET developers give a damn about HWNDs, message pumps, and the interactions between the two.
Other than that, he points out a bunch of flaws in Win32 and implies that they "leak intoOff the top of my head we have, for example:
Win32isms are abundant.
Further, your arguments that somehow cutting edge enhancements like Vista's new TxNTFS should magically appear inLet's just recap the argument, shall we?
1) Claim: Win32 is clunky and horrible
2) Response: Write in .NET
3) Claim: .NET can't do everything Win32 can do, forcing me to use Win32
4) Response: "your arguments [...] make no sense to me"
Look, if the argument is going to be "Don't use Win32, use .NET" then .NET has to do all the things that Win32 can do. So which is it?
Either I should be using .NET--in which case MS's failure to add new Win32 features to .NET is a problem--or I should be using Win32--in which case "use .NET" is not a suitable response to cited flaws with Win32. You can't have it both ways, so which is it to be?
<quote>Name a feature of C++ templates (other than multiple inheritence) that cannot be done in .NET with generics. I really tried to think of one, but I couldn't come up with a meaningful example.</quote> .NET generics are a totally different beast to C++ templates (both have their virtues, and both are useful, but they do very different things). Here's something I'd like to be able to do in .NET; something that's trivial with templates (this code is only a rough approximation as I don't have a compiler to run it through, but it's enough to give you the idea):
// etc.
Then you're really not thinking very hard; apart from some slight syntactic similarity,
template<typename T>
struct complex
{
T real;
T imaginary;
complex(T r, T i) : real(r), imaginary(i)
{
}
complex<T> operator+(const complex<T>& rhs)
{
return complex<T>(r + rhs.r, i + rhs.i);
}
complex<T> operator*(const complex<T>& rhs)
{
return complex<T>((r * rhs.r) - (i * rhs.i), (r * rhs.i) + (i * rhs.r))
}
};
I agree. It sounds to me like this guy used .NET for a year or so around 2002 when it was brand new and then left and hasn't looked again for the last six (6) years. He is the first person that I have heard accuse .NET of being "too simplistic". The .NET class library (and Java class library as well) is the definition of everything and the kitchen sink. These are extremly powerful languages and libraries that are if anything too complex.
You seem to be confused between broad (.NET supports a lot of things, like sockets and cryptography and distributed transactions and GUIs and XML and oh my!) and powerful.
.NET does a lot of different things, but .NET doesn't have the greatest underlying abstractions. For example, to name a few:
So you think that swapping out (let's say) the networking stack for something that doesn't use Winsock error codes will not break code?
How about swapping out the WinForms implementation for something that doesn't use HWNDs and doesn't send window messages in the same order?
Or implementing a crypto lib that doesn't call Win32's CryptoAPI or CryptoNG?
Yes, you could probably do it, but doing it in such a way that doesn't break anything is going to be a struggle, don't you think?
It's pretty clear from the design that
Personally, I don't actually mind that it's not especially cross-platform; it makes little practical difference to anything most people write. I do wish they hadn't billed it as being cross-platform in the first place, though; it just makes them look stupid.
What is more upsetting is that the platform it's tied to is so skanky.
Having to drop into Win32 to call some legacy thing that no-one should really be doing but which you have to do for backwards compatibility, that I could sort of understand. But having to drop into Win32 to call new features that have only just been added? Anyone saying "stop using Win32, just use
Since /. posters don't get laid anyway the technical inability to get laid without disclosing that you're HIV positive is no real impediment.
Being dead from rabies is another matter.
There are vaccinations for rabies, and prophylactics that should prevent someone exposed to the virus from developing it, but no cures. Only a handful of people have survived after developing symptoms.
That's pretty perverse. You can live years/decades with HIV with effectively no ill effect; rabies is pretty much an immediate death sentence. The number of people surviving more than a week or two is about two or three.
WPF has nothing to do with it.
0 17b-e28a-4bae-ba48-174cf47d23cd/PRI034_WH06.ppt slide 24f e47-dfc3-4e74-92a3-088782200fe7/TWPR05005_WinHEC05 .ppt slides 7, 9r o/default.aspx
WPF applications are D3D scenes, yes. But they get rendered to flat surfaces (and additionally, there's AFAIK no way to get at the underlying D3D primitves; WPF is D3D accelerated, but all the D3Dness is abstracted away).
GDI applications similarly get rendered (in software, no GDI hardware acceleration with WDDM) to surfaces.
But that's not what I'm interested in. I'm not talking about the stuff within each window (though even if I were, your comment about WPF makes no sense, because most windows are GDI windows, not WPF).
DWM creates a hundred-odd triangles for each window, and uses the aforementioned surfaces to texture each windows. But there's no programmatic access to those triangles or the surfaces or textures. The D3D scene that represents "the desktop" (and all the windows within it) is inaccessible.
Or to turn it on its head: which API call do I make to get a IDirect3DVertexBuffer9 and IDirect3DTexture9 for an arbitrary window on the desktop? If I can get to the D3D scenes, I can get to them, right? How?
references:
http://download.microsoft.com/download/5/b/9/5b97
http://download.microsoft.com/download/9/8/f/98f3
http://msdn.microsoft.com/msdnmag/issues/07/04/Ae
"but the important thing is that the API is now there for anyone to harness"
No it isn't. It's one of the things I touched on in the article (and I plan to write more on the subject).
The only thing we get (as developers) is thumbnails. We have no access to the D3D scene (i.e. the triangles and textures that make up each scene). Thumbnails don't cut the mustard. You can't do enough stuff with them.
OS X doesn't expose an API for that either (it's an OpenGL scene, but still triangles and textures), but Apple have at least done some reasonably sensible things with the facility--Exposé being the big one, but other stuff (like the ripples when you add a new gadget to dashboard) are nice too. Beryl does some interesting (not necessarily useful, but fun) stuff too--effects like the exploding windows really ought to be integrated into the scene (making more textured triangles and then animating them to "explode").
I could sorta live with DWM's lack of API if MS were at least doing cool stuff themselves. But they're not; they're just doing Flip3D. Which is, as mentioned, pointless.
It's extremely disappointing. MS have actually surpassed Apple's technology in many ways (MS are the first to have a stable, composited, 3D-accelerated desktop *with 3D-accelerated drawing primitives*--Apple don't have the latter because they can't get QuartzGL working, and Beryl/compiz/Cairo/etc. do not IMHO yet deserve the "stable" moniker--and as a practical issue, I'm sorry, but it's Apple who are the benchmark here, not the open source people, from a sheer practicality standpoint). But MS have done so much less with it than Apple. They've really missed a big opportunity, IMO. Rather than capitalizing on that advantage, they've squandered it. I think a similar complaint could be levelled at Apple (QuartzGL *still* isn't working?), but I think they've done much more with the capabilities their software has than MS. They're far better at using their latest and greatest technology, even to the extent of building whole new applications around it (e.g. Aperture and Core Image).
"As for entering a password vs. clicking a button - sudo on Mac OS and Ubuntu Linux (and probably any other sane configuration of sudo out there) ask for the password and then cache it for while so you can perform a series of admin tasks. That is intelligent."
Well, no, it isn't, because malware will attack it; OS X has already had vulnerabilities relating to this very thing (applications could detect when privileges have been raised and silently perform privileged operations in the background).
"Or I can use sudo to get a root shell or on some configurations su to root for what I need."
Much like how in Vista you can create an elevated command-prompt/Explorer/etc. that doesn't need to prompt, you mean?
"The models you are discussing are pretty much limited to information flows, and generally apply to the file space (including in-memory equivalents.)"
OK, now I see where you're coming from (though in NT they've always applied to much more than the file space).
"In this respect, the "unix based model" I'm referring to is exactly 2 levels of privilege: normal user and superuser. VMS finer grained privileges allowed a user (or more accurately a process operating on behalf of a user) to get selected privileges to do specific things. Some that I remember (from way long ago) were: Start/Stop printer queues, Exceed Disk Storage Quotas, Change File Ownership/Permissions, Change Scheduling Parameters (i.e. process priority), lock pages into virtual memory (a favorite for tuning applicatins) and my favorite, Set Process Privileges (basically this was the meta-privilege, it was the privilege that allowed you to enable to disable other privileges...)"
Ok, yes. NT has a similar set of privileges, that are generally orthogonal to the DAC permission system. For example, there's a privilege for "change process priority", one for "lock pages into physical memory", and a bunch of others. These are all actively used and enforced, although you might not notice as the privileges are available to Administrators by default anyway (though even when available they must be programmatically enabled).
"p.s. In the file space itself, VMS had a 4th permission bit, that prevented you from deleting the file. I still remember RWED as the order of the permissions (and I stopped using VMS in about 1984...) It turns out to be quite handy to say to a user "You can read/write this file, but you can't delete it." When you couple that with VMS file versioning, that provided a lot of help against accidental deletion of files by both fat-fingered users and inadvertently misbehaving software."
It's funny you should mention that; one of the rationales for the Biba integrity model is that writing is functionally equivalent to deleting anyway.
What the hell is a "unix-based security model"? A model is something like "discretionary access control" or "mandatory access control" or "role-based access control, etc.. Traditional unix (POSIX user/group/world permission bits) are DAC. So are POSIX ACLs. So are Windows NT ACLs. So is VMS. The conceptual basis behind all of these things is the same. The granularity and expressiveness may vary (ACLs are more expressive and finer-grained than permission bits), but the models are identical. Only the implementations differ.
MAC (essentially, labelling) is rarer, but is found in "Trusted" OS variants, and I think is an option in e.g. SELinux. Vista also incorporates some elements of MAC; MAC can provide one of two things; confidentiality (Bell-LaPadua) and integrity (Biba) (though they're contradictory; the restrictions that guarantee integrity violate confidentiality, and vice versa). Vista's MAC is there to provide integrity.
They don't do it because typing a password is too damn annoying.
UAC is still useful as an Administrator. Until you elevate your privileges, a UAC user *is* a regular user (essentially they have two possible tokens, a regular user token and an Administrator token, and unless you elevate, they're using on the regular user token). This means that the "protection" that it offers is the same; what differs is the ease with which you can switch between the two kinds of user (click a button vs. enter a password). So I don't think that's actually a huge problem.
Whenever something is done for which the regular user token isn't good enough, you can elevate to an Administrator token. That brings up the UAC prompt; it does it for broadly the same category of operations that MacOS X or Linux will demand root access for.
The thing is, the prompt is quite annoying. It's not any more annoying than it is on other OSes; they're annoying too. But a password is even more annoying than clicking the box. And if something is annoying, well, people are going to try to avoid it.
That's the dilemma faced by MS. If they make the thing too annoying, everyone will one way or another disable it. Originally UAC not only required a password, but also a ctrl-alt-del (so that the password couldn't be intercepted or anything). ctrl-alt-del to enter the password was too annoying; it was too intrusive. So they disabled that by default (though you can reinstate it if you want, through a GPO). Entering a password by default was also too intrusive, so again, they disabled it by default (and again, you can reinstate it across the board, even for Administrators, if you want). The reason they did this is because they want the level of annoyance to be livable. If UAC is so annoying that people outright disable it, it's useless. If it's a minor annoyance, they probably won't turn it off.
I've been using Vista since it went RTM, and I have to say, I don't see many UAC prompts any more. I did at first, when I was installing all my software, but now, it's pretty infrequent. It's certainly something I can live with. I did try cranking it right up--passwords for all users, with ctrl-alt-del to enter them--but it's far too annoying to put up with. I can't really fault MS for making the trade-off the way they made it. Hopefully, as applications improve, elevation prompts will become more infrequent (for example, I have to elevate to play Battlefield 2, because Punkbuster "needs" admin rights... this is something that they really need to fix), and when this happens, demanding a password to elevate won't be so onerous. But as things stand right now, there are just too many problematic applications. This isn't really MS's fault (it's not like NT's DAC is new...), but it is something that they've got to live with, and provide a solution for.
The theoretical underpinnings of the Windows security model are DAC, with limited MAC (specifically, the Biba Integrity Model). The MAC stuff is new to Vista; the DAC stuff has always been in NT.
The DAC model is the same as that found on typical Linux, Solaris, AIX, Mac OS X, FreeBSD, etc. installations. The Biba model is rarer (but nonetheless theoretically sound), but it's rumoured that Leopard will use it too.
In other words, shut the fuck up; you don't know what you're talking about. But I guess that's to be expected of anonymous cowards when talking about Windows.