Rob Eberhardt

Apparently someone ripped out the underlying DOS from Windows 98 and made it work as a standalone OS.  (Unfortunately, the main site is down, but there's a good info & a download mirror here.)

Why, you ask? So you can keep using old hardware, but with better disk support, FAT32, drivers, etc.

Fun stuff.  I've already installed it.  I'm looking forward to silliness like running the Windows 3.1 shell on top of it!

Links:
Main info site (seems to be down): MS-DOS 7.10 Download
Main info site (google cache): MS-DOS 7.10 Download
Download Mirror: PeteWeb.com Forums - Old Operating System Links

• .Text 0.95, extremely customized
• Windows 2003 Server, IIS 6, & MSSQL 2000
• Dell Optiplex 733Mhz, 384MB RAM, ~10GB mirrored drives, and a crappy Belkin UPS
• ~3mBps / 1mBps residential ADSL
• much love, frustration, and self-nitpicking

Nothing so fancy as a kitchen appliance, but I'm impressed anyway.

Figured I'd better justify the "meta-throbs" post category.  Hey wait a sec, was that meta-meta??

Problem:

My SBS 2003 box was getting this error several times a day: "IPBOOTP was unable to receive an incoming message on the local interface with IP address x.x.x.x . The data is the error code."

Process:

Most applicable suggestions I found said to either disable the DHCP Relay Agent service, or install a Win2000 hotfix.  No luck for me, though, since the service wasn't installed, and I'm on SBS 2003.

Solution:

Microsoft.Public Usenet - IPBOOTP ERROR PLEASE HELP.  Hurrah, disabling DHCP Relay on the LAN interface in RRAS manager.

Dean got me thinking about this -- IE has many interesting development features which are well, a bit non-standard.  Well okay, they're utterly made up with nary a W3C spec in sight.  Among them:

• DHTML Behaviors
• Databinding & Data Source Objects
• CSS Visual Filters
• CSS Expressions
• Conditional Comments
• The "defer" attribute

Here's what caught my attention about these tools: sure they're not standards-based, but they're frickin' great!

I've often said Microsoft overuses the word "innovate," especially in regards to their own products.  However, compared to other browsers, these technologies genuinely seem innovative, and are the reason I (and many others) have written so many IE-only web apps.  Microsoft didn't wait on someone else (e.g. the W3C), they just said "devs could use this", and wrote it.

(My IE-only days are not a confession I'm proud of these days, but it's true, and those developer-persuasion props are well-deserved.)

Other non-standard features have since been adopted by other browsers, creating de facto standards.  A notable example is Microsoft's XMLHTTPRequest object which is now so popular thanks to the AJAX fad). 

Fan clubs aside, I love this phenomenon -- a great tool is now widely available.  Since I can now count on it, I have more reason to write cross-browser apps. 

So hear this Apple, Konqueror, Mozilla and Opera: please forget your egos, and swipe more dev technology ideas from Microsoft.  Really.

Do it for the children?

From the IE Blog: we’ve also rebuilt the <select> element as a windowless control.

I noticed this first via Web Standards Project Buzz, where Lloydi rightly hopes they've fixed IE's myriad other SELECT problems.

As evidenced by my IE Bug Wiki participation, IE SELECT bugs demo, and IE bug solutions, this means a lot to me.

There's a ton of other great news from the IE team there, including Page Zoom, tabs, integrated search, and Quick Tabs.  It sounds awesome -- don't miss it!

I upgraded another client's SBS 2003 machine to SP1 this past weekend.  It went remarkably smoothly, but we forgot to check their smartphones' access to Exchange til today.  No connection, we checked the /OMA virtual directory, and got this error:

"A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator."

Much "jiggling" (yknow, rerunning wizards, regenerating the web certificate, etc), and googling got me no answer.  I did see this error in the Application Log, though:

An unknown error occurred while processing the current request:
Message: The remote server returned an error: (403) Forbidden.
Source: Microsoft.Exchange.OMA.ExchangeDataProvider
Stack trace:
   at Microsoft.Exchange.OMA.ExchangeDataProvider.OmaWebRequest.GetRequestStream()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices.GetSpecialFolders()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices..ctor(UserInfo user)

Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Stack trace:
   at System.Reflection.RuntimeConstructorInfo.InternalInvoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean isBinderDefault)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)

Message: Exception of type Microsoft.Exchange.OMA.DataProviderInterface.ProviderException was thrown.
EventMessage: 
UserMessage: A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.
Source: Microsoft.Exchange.OMA.UserInterface
Stack trace:
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)
   at System.Web.SessionState.SessionStateModule.RaiseOnStart(EventArgs e)
   at System.Web.SessionState.SessionStateModule.CompleteAcquireState()
   at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
   at System.Web.AsyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

What a mess.  But I recognized that "(403) Forbidden" as a web server error (although not on the actual OMA directory).  Combining that with info from similar OMA issues, I checked the /exchange-oma virtual directory's settings, and aha! it was denying access to all IP addresses except 127.0.0.1 and one we don't use.  It was not making an exception for the primary local address.  So I added that and all's now good.

So when you're having OMA problems, try the usual stuff (including checking the OMA virtual directory), then also check settings on the exchange-oma virtual directory.

Lesson learned.

related docs:
• http://www.eggheadcafe.com/ng/microsoft.public.exchange.mobility/post612531.asp
• http://support.microsoft.com/default.aspx?scid=kb;en-us;817379
• http://support.microsoft.com/?kbid=898131

I've been fighting with Outlook development again lately, custom form development in particular.  OL development is quirky, but there's one circumstance where it's downright bug-ridden: Custom Outlook forms using Windows' standard Common Dialog control.

The issues are numerous, but I'll list them as I've found them:

"The control could not be created because it is not properly licensed".

That link is to a thread in which Sue Mosher herself participates regarding her book's suggestion to use the Common Dialog on Outlook forms.  A reader discovered licensing issues with this, and Sue confesses "I think we didn't get it right, alas". 

Kudos to her for that.  But there is a workaround: when I ran into the same issue several months ago, I found (can't remember where right now, but I'll update if I do) that, due to the Common Dialog's (annoyingly dumb!) licensing, there's a right way to use it and a wrong way.  Basically, if you programmatically create the control object, licensing restrictions kick in, and it will only work on machines with MS developer tools installed.  However, if you drag/drop the control onto the form, you can programmatically use it without a hitch. 

So, drag/drop the control and code to it, instead of using code like CreateObject("MSComDlg.CommonDialog"), and you should be good.

VBScript's Native Error Handling is Broken

(Some?) Runtime VBScript Errors on Custom Outlook forms are suppressed.  Even with On Error Goto 0 explicitly set (which is the default in VBScript anyway), certain object-related errors are simply never raised. 

In particular, I was never actually getting the "The control could not be created because it is not properly licensed" error when I ran into it on users' machines (who didn't have MS dev tools installed).  Instead, that code was simply never running (as if I had On Error Resume Next set).  The only way I could track it down was by moving the code into a Windows Script, where native VBScript error handling does work:

...Not a great error message, but enough to google the answer.

Drag/Dropped Common Dialog Controls Become Invisible When Reopening a Custom Form

If you drag/drop a Common Dialog onto the form, it shows as a placeholder icon.  Save and the form template, reopen the template, and that placeholder icon is gone. 

I did determine that the Common Dialog is actually still there though.  I simply wrote some code which uses the control -- when I reopen, that code still finds and uses the invisible control without issue.  Pretty confusing to anyone who doesn't know/remember it's there, though!

Custom Field Data + Common Dialogs Cause Security Warnings

Outlook 2002 SP3 and Outlook 2003 have a security feature which restricts ActiveX controls on one-off forms.  Basically, if you open a form template or one-off form which contains an ActiveX control, OL blocks the control and gives this error:

The solution to this problem is to not use one-off forms, and to instead publish them.

Unfortunately, this is not that issue, but it's a somehow related OL bug.  What I found is that:
With items created from published custom form, which possess both custom fields and a Common Dialog control, if you save data in one of the custom fields, then you will get that error dialog on future openings of the item.

So another way of putting it:

• I publish my custom form (with custom fields & Common Dialog). 
• I can create a new item with it.  No problem.
• I can even save standard field data in it.  No problem (reopening is flawless).
• But as soon as I save data in a custom field and close, I get that dialog, and most of the form data is missing.

...I've found no documentation of this issue with this set of circumstances.  (Maybe it's that rare, but I strongly suspect others have had it, which is why I'm airing it here).

It's also a showstopper for me -- I painstakingly worked around the myriad other Common Dialog issues, but I gotta open a file and have custom data on my form.  So now I'm looking into other controls.  Hopefully Sue was right in suggesting Word's file dialog.  I don't like the external dependency, but I've checked and it appears I can do that (this time).  OR, there's also Windows' native Shell.Application object's BrowseForFolder method (which apparently has its own quirks).

For those considering embarking on the Common Dialog route, I'd recommend against it.  There are lots of alternatives.  I'll post my results with those later.

Update:

• The Word route didn't pan out -- 10 seconds to load the Word exe is way too slow for a file dialog.
• I also tried Shell.Application's BrowseForFolder method.  It's a bit clunky, though, and way too quirky.
• I think I've settled on a different common dialog: UserAccounts.CommonDialog, which is nearly identical to MSComDlg.CommonDialog.  Differences:
  • No licensing headaches
  • No OL security warnings
  • It requires Windows XP
  • "InitDir" property is renamed "InitialDir"
  ...Not bad at all.  Still nice & snappy, with WinXP as the only requirement (certainly palatable for me).

Admittedly, I haven't seen the beta yet, but I figured I'd get this out there in the hopes that someone who matters sees it...

Great idea for Windows: User Profile Templates and Machine Templates.  Essentially, they are just collections of registry settings, editable through a Tweak UI-like interface, and (most importantly) saveable as files.

User Profile Templates

These templates can be applied to existing profiles or the default user profile.  They would be editable and easily transferrable as files (Why? Because even though I'm a power user, I still like the Welcome screen).

Windows would include these Profile Templates out of the box (with example setting changes):

• Beginner -- pretty much what the default is now.
• Intermediate -- Windows Explorer switches over to details view, visible status bar.
• Power User -- All of Intermediate, plus: Quick Launch bar enabled.  Windows Explorer gets simple folder view disabled, filetype extensions visible, full path in address bar, encrypted/compressed files in color.  Windows Explorer & IE toolbars get compacted like so:
  
  Simple Folder View is disabled.

I don't care if the default templates are editable, but if not, they should be copyable as the basis for other custom templates.  (If so, they'd need a "restore default settings" option).

Machine Templates

Same idea here, but for machine-wide (HKLM) settings.  Default templates would be something like:

• Standalone Workstation -- current defaults
• Networked Workstation -- RDP enabled, NetBIOS enabled

Here's my reasoning behind this:

For Users: short of a new "GPOs for Workgroups" feature (which I'd love), power users need a way to manage workgrouped machines.  Even plain ol' Power Users with Standalone Machines need an easy way to setup a machine which doesn't require two hours of fixing stupid defaults.  Profile and Machine templates would greatly mitigate these issues for users.

For the Windows team, these templates would lessen the dev struggle between Features and Beginner simplicity.  Got a great but possibly-confusing feature?  No problem, just disable it for Beginners, and enable it for Power Users.

Also, miscellaneous Windows Explorer fixes/improvements I want:

• Bring back the file filter which Windows 3.1's File Manager had.  (Sure, disable it for the Beginner template).
• Context Menus: speed them up by any means necessary.  (Click/wait is my biggest annoyance with a busy Windows box [like while copying files])
• Context Menus: make them easier to edit (like IE, or ideally Office).  (I really want to move the "new folder" action from the "New" submenu to the main context menu!)
• Make it possible to enable the Size column for Folders (without the current crashy 3rd-party addons)
• Absorb BAxBEx's FolderBox addon's functionality.
• Make the search windows honor the "Launch folder windows in a separate process" setting.  (Currently a hung/crashed search does the same to the shell Explorer despite that setting).
• more as I think of it...

I realize some of these are advanced features