For those few who actually subscribe to my RSS feed, sorry... I'll be posting info about spammer companies I find in Guatemala so I can refer their clients to the pages. 99% of Spanish spam I receive is from companies who have been fooled by spammers. Usually I receive a good response after talking to the client directly, so we'll see. This could get interesting, in which case I'll make a separate /GuatemalaSpam/ directory and get it off the blog.


Offending Spammer:
Direct Publimedia
3 Ave. 8-37, zona 9 Guatemala
Telephone: (502) 2361-7900, (502) 2377-1272, Fax: (502) 2339-1779
ventas@directpublimedia.com

Confirmed spamming client of Direct Publimedia:
 -SuCarrito (SuCarrito.com)
   Av. Las Américas 18-25 Zona 14, Guatemala
   Telephone (502)2385-2261 (502)2459-1434 (502)24591410 
   soporte@sucarrito.com

Offending Spammer:
Estrategia Digital (Publinet):
Avenida Las Américas 18-81 zona 14
Edificio Columbus Center Oficina 2 
Guatemala, Centroamérica
Teléfono: (502) 23633084

Here is the list of confirmed clients that spam with Estrategia Digital (Publinet):
 - Nina Caps (2436-0261, ventas@ninacaps.com, 10a calle 27-67 Finca El Naranjo Zona 4 de Mixo)
 - Carolina Y H (they are a big Pharmacy and Hardware store... (don't ask about that combination)) 2368-3990, ventas@carolinayh.com
 - MoviExpress, a pirated software vendor (5692-7916)

Here is the list of unconfirmed clients that spam with Estrategia Digital (Publinet). I have not collected an email from them, but have good reason that they have sent out spam or soon will, as they are dealing with Estrategia Digital.
 - Inter Mall (1a. av. 15-54 zona 10, 2470-2964)
 - Unnamed perfume store “La Perfumeria” (calling them gets nervous people saying “umm... perfume... yea, hey, call this number and talk to this guy...“) 5615-2155, 2238-6467. 

Install took about 15 minutes. I installed the database server + workstation components. No reporting, analysis yet. Maybe my eyes were playing tricks on me, but it seems that it will install multiple components simultaneously if dependencies are satisfied. That's neat. Anyways, the setup is a very slick setup, and I didn't get any annoying errors about having to reboot (which always seems the case with SQL 2000). No errors reported.

After you are done, it tells you to run SQLSAC: Surface Area Configuration. Wow, this is very cool. Right in your face: Do you want local only connections, or remote connections via TCP/IP or named pipes or both? For the many people that have a single-server setup (i.e., tons of web sites), this should be a nice and easy way to lock yourself down.

The old “client network setup” and server setup is replaced by an MMC-based configuration manager. Quickly view your setup. Nice.

The old help system has been replaced by the new kind (Help 2?). In the earlier versions of Yukon, this meant it sucked, as the help was very messed up. But now, like Visual Studio 2005 Beta 2, the help flies and works just great.

I tried adding an operator and adding an alert. While the alert shows it's been triggered a few times, the operator is never contacted (email). I set up “Database Mail”, but that didn't seem to help either. The help files had some really lame advice. Like “to set up notification, click notify” kind of stuff. Spent probably 10 minutes trying to get some notification going, to no avail. :@. Anyone know how to do this?

One that that is great about the Studio is that things actually work. In the earlier versions, nothing was implemented. I've successfully attached my SQL 2000 databases. This is a huge thing, as now I know I can just upgrade my servers and go full 2005! Bye bye SQL 2000. It's been great.

I really, really, like the SQL Server Management Studio. No more having to go to Query Analyzer separately. Now I can do everything right there. Very, very, nice.

The only ugly thing is that the grid UI they have looks really old and ugly. It still reminds me of SQL 2000's Query Analyzer or something. It's also terribly slow. The rest of the UI seems fast, but those damn grids are just screwed up. I can actually see the lag. I hope they get replaced.

Database diagrams are back (like they should be!). This is great. However, after importing my SQL 2000 database, I couldn't view my existing diagrams, and trying to create one results in:

Microsoft SQL Server Management Studio
----------------------------------------
Failed to retrieve data for this request. (Microsoft.SqlServer.SmoEnum)
----------------------------------------
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission. (Microsoft SQL Server, Error: 15517)

However, it did work fine on a new database. The diagrams are way uglier than before, but whatever. At least they are there. Having them makes up for the table editor sucking. Seriously, the table editor is as bad as Visio's table editor. This means you must click a field, and then go down to the bottom and use this little property editor to set basic parameters. I just don't get it...

Support in Visual Studio looks like exactly what I'd expect from a development standpoint. It appears that you get the entire tree of SQL Management Studio from the database on down. Cool.

Well, anyways, that's my first quick look. I'll be using SQL 2005 as my primary database from now on, so I'm sure I'll come up with a lot more feedback.

I got my Windows 2003 machine installed without a problem (well, except for the bloody floppy disk drive being needed). After installing SP1 and Office 2003, I decided to go put on what I had been waiting for since Saturday: Whidbey Beta 2.

Install went smooth and fast. I think it was under 30 minutes (not inc. MSDN). I install almost everything except J# (haha), Crystal Reports (yuck), and Dotfuscator (I have way better!).

I reboot, install MSDN, run Visual Studio.

---------------------------
Package Load Failure
---------------------------
Package 'Microsoft.VisualStudio.QualityTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' has failed to load properly ( GUID = {A9405AE6-9AC6-4F0E-A03F-7AFE45F6FCB7} ).

Damn, there goes all the testing features. While all the pretty icons are in, none of them work.

*Update! A friend who works on Team System says that not installing the Team Foundation Client will cause problems with Beta 2. I'm also told that I don't need to wait to install TFS first. So, I'll go install it. Thanks, I hope that works!

Next, open up a project, try the properties. Everything works smoothly. The properties window even closes correctly. This was a major pain point before.

Performance testing. Oh, wait, that doesn't work:
---------------------------
Microsoft Visual Studio
---------------------------
Could not load type 'Microsoft.VisualStudio.Performance.PerfWorkItem' from assembly 'PerfPkg, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
---------------------------
OK  
---------------------------

OK, well, I don't use those features everyday. I'm sure someone will find a fix shortly. I haven't even looked yet.
*Update: Supposedly related to not having the TF Client installed.

I got a crash while saving my settings (I can't resist going through all the nifty options). But I tried again and it worked.

Graphically, the whole program looks quite polished. Except for the test on the splash screen not being antialiased, and a few icons here and there (solution icon in the solution explorer), it looks very refreshing. The docking tabs (is that what they are?) for the toolbox, solution explorer, etc, are redesigned. A tad space wasting, but attractive. Dragging a toolbox around has a nicer targeting system. There have been a lot of great colourizing enhancements. (Yes, and my suggestion of maroon-coloured strings is now a default! Yea!)

Seems quite fast. Compiling my only real Whidbey app (~25K lines of C#) works great. UI does not lock up while compiling. Compiling web projects does not take forever (before, it'd hang for about 10 seconds).

ASP.NET... ok, here's the big one... *IT IS NOT FIXED*. Yep. Everyone (like me) who was hoping that the ASP.NET team would stop tripping before Beta 2... welcome to reality. You're gonna develop your web apps like ASP Classic, and you're gonna like it, dammit.

Basically, it boils down to that every bloody class is its own freaking assembly. What a pain in the ass. I mean, seriously. They do ASP.NET 1.0, and blow everyone away. Then they think that even though people like me have been saying it should be this way for years, they feel it is too early to introduce real app development to web apps. If you want to share code, you have to put it in the “App_Code“ directory. I guess this helps people who are used to <!-- #include “inc/functions.asp“ -->.

Another thing, ASP.NET isn't listed in the new project dialog. Somehow the ASP.NET team things that they aren't projects. I'd *love* to find out why this is, besides “idiots who could barely figure out PHP couldn't figure out ASP.NET need help“. Why I have to have this “file based“ “web project“ thing just keeps annoying me.

But, despite my complaining, I will, like an abused girlfriend, keep coming back for more from ASP.NET 2. The other features (i.e., great designer, awesome C# code editor, freaking fantastic framework) outweigh the huge annoyance that ASP.NET projects have become. I swear, if it wasn't for ASP.NET's new features (like Master Pages), I would not, repeat, would NOT, develop new web apps with VS 2005. But, they know this. They know their feature set is so sexy, I'm gonna happily get smacked around. They know I'm addicted and will play whatever little game they want to play to keep using. They want to treat me like dirt^H^H^H^HMort, fine. Whidbey is such a huge jump ahead that I'll just have to move on. Really. I will. Eventually. BTW, I'm not just complaining for no reason. Even on the relatively small projects (say, 18 project solution, ~100K lines) that I've done, I can't imagine ever, ever, using this new project model.

Of course, maybe I'm just missing something, and it actually is fixed. If I missed it, then I guess I deserve it. But I'm pretty sure they aren't hiding much.

Moving on...

I am also going to install Team Foundation Server and the Team Client. In the TFS setup, it says to install the client after the server (*Update: which might be incorrect). And the server needs SQL Server 2005, so I'm waiting for that to finish downloading. Finally.... real source control, defect tracking. Wow. I'm also looking forward to playing with the revised (hopefully revised) data tools. The ones in Beta 1... were next to unusable. I understand they've been fixed and features left in (like diagrams).

I heard there was community integration, and sure enough, there's a Community menu item. However, clicking anything there ends up with a:
---------------------------
Microsoft Visual Studio
---------------------------
The operation could not be completed. The RPC server is unavailable.
---------------------------
OK  
---------------------------

Maybe the install is messed up. Or maybe it's a crappy error message for “Couldn't contact Microsoft's community servers.” No idea.

In C++, I've had more success with the “go to reference” feature than before. This is a non-Microsoft C project. I'm using VS as the editor only. The experience seems to be improved over Beta 1. Cool.

MSDN works! It's fast too! Quite fast actually. And so does the search (well, haven't tried in detail, but before it was pretty crappy).

Upgrading. On my 25K line project, I had 34 errors and 10 warnings. The majority of them were from ASP.NET's changes (the ones that improved it from Beta 1). Not bad!

Well, that is my first quick glance. I'll have some real time during the next while to really get involved.

As of right now, I have 760GB in my computer, temporarily. My Western Digital 120GB IDE drive had an error a month ago, so I got some Seagate 7200.7s and put them on an Adaptec SATA RAID card (RAID 1). After I remove my old drive, and discounting the mirrored drive, I have almost half of a terabyte of storage on my local computer (and it's mostly full already).

What's interesting is that almost ten years ago, I was making the similar claim about having 500MB -- half a gigabyte! Most other people I knew either didn't have a computer, or had much less than 500MB. Heh, and today, I've got 1.5GB of RAM alone :P.

Oh, one little rant. Windows setup sucks. Horribly. If you've had to install Windows onto a “3rd party mass storage device” (well, duh, Microsoft doens't make hard disks), you know what I'm talking about. It actually requires you to have a floppy disk drive. A floppy! Who the hell has one of those? Oh, you can do the $OEM$ thing, if you can figure it out. Microsoft doesn't have any guide on adding your drivers to the Windows boot CD. Nope. I mean, would it have been that difficult to have it also be able to load from a CD-ROM? I've got 2 spare CD burners here. Not a single FDD! I had to get someone to bring one down, and then waste probably an hour trying to get it to work, find an actual diskette that worked, etc... Sigh.

Well, at least I hear Longhorn will have an amazing setup system...

I just read that Adobe is going to buy Macromedia. Ever since I touched that atrocity named “Flash”, I've been hoping that this would happen. I'm sure anyone who's ever dealt with Macromedia's “Freehand” will also let out a big sigh of relief. I won't say it's a brilliant move, because I don't know of a single good Macromedia product. Only that entrenched Flash thing...

Although, it's actually doubtful that Adobe will fix Macromedia's products, because their users would get all confused. In the past, when I've had to work in such environments that required dealing with “designers”, I've found that Mac users are only surpassed in cluelessness by Freehand users. That's saying a lot, since I've had a Mac designer tell me that Windows can't “draw a smooth line”.

As far as Flash... Adobe has a Flash product. “InMotion”. And for actually doing animation, it rocks Flash. But Adobe is not really that great at doing motion products. Their still-image stuff is the best, but Premiere, After Effects... blah. If you want to see what some REAL compositing/editing software is like, try out: www.discreet.com.

Now, if discreet (Autodesk) could just manage to get Adobe, we'd be living in a nice world. This is in spite of Microsoft selling off Softimage to *horror* Avid. Microsoft should have worked on a fork of Softimage, scaled down to home users. Movie Maker|DS anybody?

Wow. It's up. Downloading @ 50KB/sec right now. If you don't know what it is, I'll give you a hint. It starts in Visual, ends in Studio. Beta 2.

On Monday I'm getting (2) 200GB SATA-II drives to use with my Adaptec RAID card. I'm going to run RAID 1 (mirror) just in case my daily backups + 2nd day archive backups + weekly DVD backups fail. Am I paranoid?

At any rate, that means installing Windows on the new system. And along with that, Visual Studio Beta 2, on a nice, clean, machine. Perfect timing.

I just used the coolest feature in a while: VS2005's Call Browser.

I'm currently working on some firmware for IP phones and adapters. The chip is the Intel 8051, as used by Centrality Communications in the PA168. It's actually quite fun, programming for an 8-bit system. Apart from writing in C (instead of such high-level things like C#), writing for embedded systems like this adds its own interesting things, like having to decide where a variable will be stored (I think there is 3 different storage locations a variable can have with the 8051). Oh yea, and having to keep things really small, and really fast.

At any rate, I am not that familiar with the entire design of the system, and I just want to focus on adding features to the IAX2 implementation (cause SIP sucks!). A large part of my work is to figure out how things work. Having the Goto Definition (F12) is great for finding specific symbols, but doesn't help with the flow. Up until now, I've been Finding in Files for a specific method, then chasing things down by recursively Finding in Files until I figured out how things are called. This happens a lot, since these devices support 5 protocols and use #ifdefs and generic calls to interface with the different protocols. Add to that 8MB of source, and it's no small task.

This morning, I remembered I had seen a “Call Browser” window in Visual Studio 2005 a while ago. Edit: Apparently this isn't a new feature and has been around since VC6 (at least). Well, it's new to ME, and it's still very cool.

Here's an example. Let's say I want to add attended transfer (where you have a call, press transfer, dial a number, talk to the new call, then hangup to connect the two). I'm looking in the source I'm familar with (the IAX protocol area), and see iax2_hangup(). That's a packet-level call, so when someone physically hangs up, that, somehow, gets called. Where? Well... right click the function, Call Browser -> Show Calls To:


Click... click... click... bingo. Now I've got a complete grasp on the call flow that would send a IAX_COMMAND_HANGUP. My old way (which makes me feel stupid now) of browsing source doesn't even come close. A lot of programming these days is managing complexity. It's all about making the best use of our limited brainspace (some more limited than others). 17 lines/1 small diagram. That's all it takes for me to see this complete flow. How much mental capacity does that require versus browsing multiple locations in 4 different source code files?

Well, I didn't get reawarded this year, so today's my last day as an MVP. I didn't get reawarded this year because, lets see.... I didn't do anything to deserve the MVP award. I wholly agree with their decision, and I'm quite sure another way more qualified person is now in the program. I'm just really busy with this thing called “real life”. Growing up, I wasn't sure it existed :). Anyways, with a baby and some serious work issues coming up ahead, I doubt I'll be able to do much for the community for the next while anyways.

Anyways, it was a great ride, lots of fun. Thanks!

Apparently this was recently published: http://www.securityinnovation.com/resources/linux_windows.shtml

To summarize, RedHat Enterprise Linux 3 had 132 security issues (with a minimal configuration), whereas Windows 2003 had 52 for calendar year 2004, *when configured as web servers*. This includes a webserver (Apache/IIS), app platform (PHP/ASP.NET), and DB (MySQL/MSSQL). Only issues fixed in 2004 were counted.

A few points:
 - They took a default install of Windows 2003, stating that it's too hard to get rid of stuff like IE. Thus, any patches applying to Windows2003 were included, regardless of if they could be exploited or not. This of course affects Windows' rating.

 - Same for RHEL. RHEL installs a lot of stuff that might not be in use and not exploitable. I'm guessing that what accounts for the very high numbers on RHEL. Then again, it's a fair comparison for average users (like myself, who just installs RHEL/Windows out of the box and doesn't really screw around with a lot of stuff).

 - However, assuming super-competent admins on both platforms, I'd expect the exploitable vulnerabilities to be close to zero on both platforms. I.e., if admins took precautions to install patches quickly as well as lock down services/systems as soon as a vulnerability was discovered. However, that's not realistic at all, and that's why a study that just takes a standard install is needed.

 - They used MySQL on RHEL. While this might be correct since people use it... MySQL is junk. Seeing as how it could be barely considered a DB and how poor it is overall, I wouldn't be surprised if MySQL accounted for a large amounts of vulnerabilities.

I think the study should have broken down where the vulnerabilities were in the product. Not knowing what was the fault of IIS, or MySQL, etc. makes it hard for people to compare the products for their own usage.

The study also mentioned the “Days of Risk“, i.e., from when the vulnerability was first publically reported to when it was fixed. RHEL will always have an instrinsic disadvantage here. Since most issues are related to open source, it's harder to do private reporting.

Second, there are vulnerabilities in Microsoft software that are fixed, but never reported. For instance, IIRC, the “GIF Integer Overflow” problem that was found after some Windows source was leaked was fixed in newer versions of IE/Windows, but never reported (until the source was leaked). I also know that from personal experience, you can report a bug to MS, and if you don't go public with it, they'll roll it up in an SP or next release. These issues are just [almost] intrinsics of open vs. closed source.

Some might say, “Oh no, there are issues in Windows 2000 that aren't publically published!“, but the same exists for RHEL. The difference is that some of these “private“ issues can get fixed in newer versions without ever becoming public, while in open source, it is much harder to do so.

Now, some people are up in arms since it was not disclosed that the funding came from Microsoft. Bruce Schneier, for instance, is saying that people will just ignore the results and focus on this possible bias. That's BS. Since the methodology is published, it's not exceedingly difficult to recreate the results. People should do that instead of bitching about who funded the research. My guess is that people who are satisfied with the results don't care to go recreate them, and those who aren't are afraid that they'll find the same results and thus have no argument.

I just read that Visual Studio Express will be $49. This is what... $30 less than the usual “Standard” edition (which I can't imagine anyone can actually use :P)?

Why bother charging $49 for the product? $49 isn't much, but it's a huge jump from free. Why free? That way, to evangelise, you can just throw a bunch of free DVDs at people and let them use them. Say, for instance, academia.

With the standard line at $99, doesn't seem like there's much reason at all for an Express version...

I'm doing my own realtime support for Asterisk, in an attempt to make it scale. Asterisk is nice software, but straight out-of-CVS, the performance for high volume (say, over 20,000 clients) sucks. There are also other inconviences with using a file-based store to determine how to route calls. Mainly, it's inflexible and hard to achieve high-perf when everything is based on a large .conf file. Not to mention that Asterisk uses linked lists for everything so looking up any user is an O(N) op (and parsing the users file is O(N*N) by default!). So, I'm going to put my own logic as a replacement for some of the critical parts.

One of my concerns was performance. Since I'll have multiple Asterisk clusters banging on my .NET code (via SOAP), I wanted to ensure the whole end-to-end process was fast enough.

I used gSOAP to create the C code on Linux. gSOAP is seriously nice. At least an order of magnitude easier to use than I expected any SOAP library that works on Linux would be.

I created a simple test. I made a database with phone numbers and codecs. The idea is that when an incoming call comes in, Asterisk will use my code to SOAP over to my Windows machines, get the data, and then go on its merry way.

My Asterisk machine is a P4 2.4GHz, 512MB RAM (but, I have a Gnome session running on it). My Windows XP machine (I tested against my desktop) is a P4 3GHz HT, 1.5GB RAM. I'm running ASP.NET 2 Beta 1 and SQL Server 2000.

The test program consists of a loop (count 5000) that generates a random number, then uses gSOAP to ask for the codec for that number. Simple, tight.

The results on Linux are particularly impressive. Each instance of the test app only used a max of 4% processor, and under 1MB of RAM. The bottleneck was definately inside ASP.NET. To simulate more load from other machines in a cluster, I ran 1, 2, and 4 instances of the test program. Also note that background tasks on the XP machine used up about 10% of the CPU.

Results:
 Single process (5000 total requests): 
  Total time:                   18 seconds (0.0036s/request)
  Requests per second:   277
  ASP.NET/IIS CPU:          30%
  SQL Server CPU:            4%

 Dual process (10,000 total requests):
  Total time:                   23 seconds (0.0048s/request)
  Requests per second:   384
  ASP.NET/IIS CPU:          60%
  SQL Server CPU:            7%

 Quad process (20,000 total requests):
  Total time:                   42 seconds (0.0052s/request)
  Requests per second:   476
  ASP.NET/IIS CPU:          80%
  SQL Server CPU:           10%

These results are encouraging enough that I'm not worried of the performance impact of using SOAP with Asterisk. My target was to have a response in less than 0.1 seconds. Although, anything under 0.5s would be quite unnoticable to a client. Even in tests with more threads, my single request response time was always way under 0.1 seconds.

Also, as far as I know, Whidbey Beta 2 (the version I'll go live with) makes some performance improvements. And also, IIS6 on Windows 2003 is much faster than IIS5.1 on XP. At any rate, a single proc desktop machine serving 476 RPS? That's pretty damn good perf if you ask me!

[OK, this was brought on after a night of fighting with the latest VS2005 “Made For Mort(tm)“ features in VS2005 and after hearing even more about the silly “VB Unmanaged 4Ever Petition“. Yes, I know, there are professional, intelligent, etc. VB programmers who signed. I also started programming in BASIC. And yes, I know this suggestion is as bad as the actual petition.]

Sign by leaving a comment.

A PETITION TO END THE ATROCITIES OF VISUAL BASIC

We would like to suggest a path for the future development of VB6 and similar apps to put an end to the crimes against the world committed by worshipers of Microsoft's product, Visual Basic. This path will help anyone who should be working with computers on a technical level.

OBJECTIVES

We ask that Microsoft stop catering to low-end, “Mort” developers, especially those who cling to past glories achieved through VB6.

1. Preservation of Assets
    Microsoft should not:
        - Force customers to uninstall Visual Basic 6
        - Push a patch out through Windows Update that disables the VB6 runtime
        - In any way, magically make VB6 stop working at the end of March, 2005

2. Discontinued support for Visual Basic
        - Medical trials have shown strong correllation between Visual Basic usage and degration of the brain, notably the areas that deal with change and improvements.
        - Microsoft should take responsibility and make its products harder to use to raise the level of entry.

3. Ease migration of deprecated developers

        - Provide “Career Days” where developers can learn about and get jobs in exciting industries, such as textiles and hospitality
        - Promote local support groups and 12-step programs
        - Sponsor emigrant visas 
        - Provide a VB6-to-C++ reverse engineer tool.

SUGGESTED APPROACH

We believe the best way to meet these objectives is to drop support for VB.NET after Visual Studio 2005 (Codename “Whidbey”). For brevity, we’ll call this “natural selection”.

To quell proponents of “VB.COM”, we suggest explaining that “VB.COM” and “VB.NET” are so completely unlike C# and C++ that it sounds like a bad joke. We also suggest that Visual Studio team members personally make disparaging comments about how silly this is. While personal attacks and racial slurs shouldn’t be used, general stereotypes such as “…people who think architecture means making a wrapper for MsgBox” are fine.

CONCLUSION

With VB.NET out of the picture, less “Morts” will use Visual Studio. Microsoft can then focus on designing a strong framework and toolset that doesn’t worry about people who won’t understand why System.Windows.Forms.MessageBox.Show doesn’t work “as it should” in an ASP.NET page.

Overall, we feel this will enable a better environment, and more robust software being created in the industry today.

So, they're not only asking Microsoft to create a new version of old VB (i.e., not .NET), but they're also asking it to be integrated into the VS.NET v8+. Some have cited C#/C++ as an example of this. 

HAHAHA! Man, if this doesn't show how clueless some VB programmers are, nothing does. I mean, seriously, come on! They actually expect MS to say “ok, sure we'll make VB6.5 v2005 and go away from managed code”? And they think that integrating VB6 right into VS.NET will be a piece of cake? This proves that many VB devs really are clueless when it comes to designing apps and think that there's some magical power that just makes everything work. The sad part of this is that some of these people are MVPs... I thought that MVPs generally had a relatively high knowledge level and wouldn't come up with silliness like this...

Ran into this problem after uninstalling MS SQL Server 2005 beta and trying to open the Enterprise Manager: “SQLDMO has not been registered. Please re-install SQL Server and try again.”

Just go into C:\Program Files\Microsoft SQL Server\80\Tools\Binn\ and run “regsvr32 sqldmo.dll”. Things will work again.