Hey there MS Dudes and Fellow Insignifs. In concept, Channel 9 seems like a great idea. I think its extremely important for Microsoft to open up dialogue with developers (and everyone, for that matter).
If its really "dialogue" you're after, I've certainly got plenty to say. Honestly though, I'm not quite sure whether that's what you're hoping for.
For instance, I could tell you guys everything I think is wrong with Windows and other MS products. But would anybody
really care what I think?
What I'm interested in are a few items...
Whitehorse: This sounds like such a cool idea that can go so horribly wrong. It gives me goosebumps. At the same time I'm hoping you (or Marketing) are not sitting there promising "It'll make code so easy even a business analyst can do it!"
I actually kicked a vendor out from a presentation he was giving for saying that one...
Insight into the future: I see software heading to service based objects, but alot of people i talk to aren't even sure of the concepts. I see a world where we move away from the PC's and to more portable network devices...alot of my peers
are still in the VB 5.0 world. I'd be curious if others thought like me with the idea of network appliances and portable computing devices being the future and getting away from the desktops.
XBox: The xbox is basically a sealed up PC, any plans for MS to turn it into a "Home Automation Center"? I've seen the media center OS, might be nice to sort of put the two together...
Ok, i'll leave stuff for others to bring up, but those are a few ideas off the top of my head.
You think we don't sit around at lunch talking about the ways our products suck? That gives me some ideas for some more video interview questions.
Please do continue. One thing I try to do is try to be constructive. Give some ideas of what I'd like to see done. It's one thing to say "that sucks." It's another to say "that sucks, but here's how I'd like to see it fixed."
Perspective Note: I'm not yet very experienced as a software developer, although software architecture fascinates me.
Alright then, I'll start by being blunt:
The structure of the Windows product (every version I know of from 1.0 to Server 2003) does in fact suck. I hope that doesn't offend anyone too terribly.. but yeah, there it is. One of my biggest issues here is:
Program Files + Registry
Installed applications are organized just horribly.. installed into one or more directories under Program Files and registered in anywhere from 1 to 100's of locations in the registry.
Now, I realize application developers have a lot of control over how cooperative and modular their applications are, but it really just shouldn't be allowed to work that way.
In many ways the current structure is a serious improvement over DOS -- and yet with DOS, almost all programs were 100% modular. Move or delete the directory, maybe REM out or delete a couple lines in Autoexec.bat and Config.sys -- bada boom, no more Application
Dependency handling is, imho, vastly superior to Linux (oops, or is that a censored word here? ), but still leaves a lot to be desired.
I've always been interested in some kind of clearly defined Multi-Tier model where applications have a very clear single-parent hierarchy of dependency, and where specific types of applications, components, and dependencies operate at very specific layers in
the architecture. In such a model, reinventing the wheel when it comes to higher-layer APIs and Windows components would be a big No-No, so system APIs would have to be well-defined and well-documented, but very flexible.
Also, instead of one massive, universal registry, Applications should have their own registry databases for settings. These registries could even have encryption for keeping inexperienced or malicious users from monkeying with sensitive settings like product
Installation should be completely modular -- applications should "Plug In" as easily as Red Hat Linux Packages (RPMs), only without the dependency issues -- and Uninstallation should never leave any trace that the software was on the system.
I have more to say on this but I don't know if I'm making myself clear (and this post is getting long), so I'll cut it short for now.
irbrian, I like what you have said and I agree with everything. I do feel compelled to say that what MS has done with .NET has in a big way reduced the problems that you mentioned. We now have true Xcopy deployment (so long as the .NET framework is installed).
We also are able to store the necassary application configuration parameters in an app.config file in an XML format.
I have to give MS big praise for exposing configurations from ASP.net apps web.config, through a console apps app.config. Thanks for using a format that is open and will allow interoperability.
For COM you will still have to register your .NET components. But for purely .NET applications, you can install your components into the global assembly cache and you are good to go! w00t!
I agree wholeheartedly about the registry - it's outdated. I think a great idea in Longhorn would be to give each app its own registry, then trick older apps into thinking they're writing to the big registry. That way you have backwards compatibility but
can move beyond the system bloat.
I really like how .NET is making deployment easier, but the registry problem exists so long as .NET programs can access the registry, and the global assembly cache seems like just another variant on "throw everything into system32" albeit a better managed variation.
I'd much rather have every app be self-contained.
registry is WAY to complicated....and cluttered...i know it's nessasary
Just a comment on the windows sucking post...
I agree that it is way too bloated.. but without the registry, how do you have interoperability between applications?
How does one program know where the other one is?
Programming in .NET is one thing, where you can include your DLLs in the running directory and it just works, but not all programs written for the windows operating system are written in .NET so you need some kind of map to show these programs where to go
to get the dependencies that they need.
IMO the registry, or some other type of "map" for 3rd party applications will always be required, it would just be nice if it wasnt so cluttered.
Comment removed at user's request.
A little known feature of Windows XP is reg-free COM. By authoring a manifest XML file, you can deploy non .Net apps in an XCopy way. In fact, there is even a non-managed GAC (global assembly cache, think system32 with strong identity control) that you
can install these native assemblies (COM dll + manifest) to. Here is a good reference:
I think a great idea in Longhorn would be to give each app its own registry, then trick older apps into thinking they're writing to the big registry.
How would an application query for outside application's data? ie The path to another application or a Windows setting.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.