RA wurde von Software-Ingenieuren entwickelt, die vorher für die fünftgrössten Software-Herausgeber tätig waren. Die Wahl von Architektur und Implementierung in RA basieren alleinig auf Kriterien der Effizienz, und nicht etwa auf mangelnder Erfahrung oder "strategischen" Bündnissen (wie z.B. der Art von Bündnis, die die letzte Version Ihres Word-Processors derart verlangsamt, dass Sie alle zwei Jahre einen neuen Computer kaufen müssen). 

Wir haben lediglich versucht RA (und den DS) von Anfang an so optimal wie möglich zu gestalten.

• RA benutzt Fremdbibliotheken nur, wenn der Sourcecode verfügbar und auf andere Betriebssysteme übertragbar ist.

• RA benutzt keine Windows-Internals, wie z.B. System-Hooks oder Low-Level-Drivers.

• RA wurde in C++ Code programmiert, der auf andere Betriebssysteme übertragbar ist, und der es uns ermöglicht jetzt auch Mac- und Unix-Versionen in Angriff zu nehmen. 

• Die Übertragbarkeit bringt einige interessante Nebeneffekte mit sich, die den RA-Code:

  • kleiner machen (ein Rad neu zu bauen machte weniger Aufwand, als der vergebliche Versuch ein schiefes Rad zum Rollen zu bewegen)

  • schneller machen (ein Rad neu zu bauen machte weniger Aufwand, als der vergebliche Versuch ein schiefes Rad auf Touren zu kriegen)

  • zuverlässiger machen (ein Rad neu zu bauen stellte sich als sicherer heraus, als die Benutzung eines schiefen Rades)

  • einfacher in Wartung und Verbesserung machen (wir benutzen keine fertigen "Black Boxes", die wir im Bedarfsfall nicht abändern können)

• Optimierung ist zwar eine aussterbende Kunst, jedoch haben wir unser Bestes gegeben, um RA klein und schnell zu halten.

• Dazu haben wir eine einfache, logische Methode angewandt:

  • es muss funktionieren (Alpha-Versionen)

  • es muss gut funktionieren (Beta- und Verkaufsversionen)

  • es muss schnell sein (kostenlose Updates)

• Wir stehen auf dem Standpunkt, dass RA-Benutzer unsere bestmögliche Feedback-Quelle sind

Trotz all unserer Anstrengungen, hatte RA auch ein paar Bugs. Sobald ein Bug gefunden wird, werden die korrigierten Versionen so schnell wie möglich geliefert, meist innerhalb von weniger Tagen, manchmal sogar innerhalb von Stunden. 

Von Zeit zu Zeit kam es vor, dass RA nicht sonderlich gut auf einer der 24 bestehenden Win32 Windows-Versionen lief (hinzu kommen noch die Service-Packs, die Versionen von Internet Explorer und MS Applikationen, die das System verändern (wie Office oder IIS) etc.
Man hat es also mit mehr als 400 verschiedenen Plattformen zu tun. Da kommt Freude auf...)

Meist lag es an Versionsproblemen der System-DLLs. Die Probleme der Windows-DLLs sind äusserst zeitaufwendig und frustrierend. Dem hinzu kommt noch, dass Benutzer dies nicht verstehen: Da  Windows nicht abgestürzt ist, sieht es für den Benutzer so aus, als hätte unser Programm einen Bug, nicht aber der Code von Microsoft. 

Der Benutzer kann sich also nicht vorstellen, dass die traurige Wahrheit anders aussieht: "Windows" ist keine Plattform, sondern eher eine zusammengewürfelter Haufen von Betriebssystemen, die von verschiedenen Teams geschrieben wurden, die manchmal versucht haben so etwas wie Kompatibilität in die ganze Angelegenheit hereinzubekommen. Das ist zwar für den Benutzer nicht ersichtlich, wohl aber für einen Programmierer. Je nach der Windows-Version, die zu benutzen Sie beabsichtigen, ändert sich sogar die Art und Weise wie diese programmiert wurde. Schlimmer noch: Windows-API bietet Funktionen, die - wenn sie schon einmal für alle Windows-Versionen verfügbar sind (was nur selten vorkommt) - in den verschiedenen Windows-Versionen nicht die gleiche Verhaltensweise an den Tag legen. Sie können funktionieren, oder nicht funktionieren, unterschiedlich ausfallende Resultate liefern, oder einfach nur Ihre Applikation oder Ihr System zum Abstürzen bringen (Ja!). Manchmal muss der Programmierer ihnen verschiedene Werte zuordnen, um sie dazu zu bringen korrekt zu funktionieren. Sie können auch der Grund dafür sein, warum Ihre Applikation sich nicht aufrufen lässt, selbst wenn Sie die fehlerhafte Funktion gar nicht benutzen (Sie müssen beim Starten herausfinden, welche Windows-Version benutzt wird, und ob alle Funktionen, die Sie benutzen möchten, verfügbar sind). 

Diese Schlamperei ist zwar schlimm, liesse sich aber noch ertragen, wenn sie zumindest entsprechend dokumentiert wäre. Aber selbst wenn Sie bei Microsoft jährlich eine Prämie für das MSDN-Abonnement zahlen, werden Sie die Erfahrung machen, dass diese Dokumentation genügend Irrtümer und fehlende Information aufweist, um Ihnen jeden Tag des Lebens zu verderben. Sie können dort sogar Funktionen finden, die zwar dokumentiert, jedoch im Microsoft C++ Compiler gar nicht implementiert wurden...

Wenn Sie ein Programm für Windows schreiben, müssen Sie es mit den folgenden Bugs aufnehmen:

• jene, die Sie selber schreiben (leicht zu finden und zu beheben)

• die des Compilers (kniffelig aufzuspüren und einfach zu korrigieren - wir mussten viele fehlende Aufrufe selbst schreiben)

• die, in der Microsoft-Dokumentation (am Ende kommen Sie zwangsläufig an einen Punkt, wo Sie Ihre 'eigene korrigierte' Version des MSDN erstellen)

• die, aller verschiedenen Windows-Versionen (schwer zu isolieren und zu identifizieren und schwer korrigierbar)

Die meisten Bugs in Windows lassen sich nur schlecht isolieren, weil sie nur in einer oder zwei der existierenden Windows-Versionen auftreten. Ein Programmierer kann nicht jede neue Zeile seines Codes auf 14 PCs ausprobieren. Dazu leben Programmierer nicht lang genug. Ein Spitzeningenieur kann das zwar tun, aber es gibt niemanden, der alle Funktionen eines Programmes auf 400 PCs austesten könnte - was nötig wäre, wenn man einigermassen sicher sein wollte, dass das Programm sich stabil auf einer unstabilen Plattform wie Windows verhält.

Not convinced? OK. Here is a piece of Microsoft Office Visual Basic's source code: (yes, it's real)

//  Function:   RunCommandEx //  Synopsis:   runs the given command in the current session, more robust // than RunCommand //  Arguments:  none //  Returns:    S_OK if success //  History:    October 3, 2000 - created [name withheld to protect the guilty] HRESULT RunCommandEx(LPCWSTR szCmdLine) {      DWORD dwTry = 0;      HRESULT hResult = S_OK;      // try run command 3 times at most      while (dwTry<4) {           hResult = RunCommand(szCmdLine);           if (hResult!=E_FAIL) {                // we succeeded                break;           }           dwTry++;      }      if (dwTry==4) {           ATLTRACE(L"COuld start the command even we tried 4 times\n");           ASSERT(FALSE);      }      return hResult; }

Robust? Safe? Clean? Useful? Hmm... not really.

What Microsoft developers think about it? An internal Microsoft memo sent to Bill Gates on Febuary 21, 1997 is clarrifying the question :

"The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead. It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO total cost of ownership, our lack of a sexy vision at times, and many other difficulties. Customers constantly evaluate other desktop platforms, but it would be so much work to move over that they hope we just improve Windows rather than force them to move. In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago." 

-Aaron Contorer, Microsoft head of C++ development

Why Windows is so frustrating -even for Microsoft employees? Microsoft never tried to deliver technology, what they did was to apply a very high tax to the whole IT market. Today, Microsoft is so rich that that even governments can't enforce justice decisions against it.

Mann sollte meinen, dass es ausreicht, wenn Programmschreiber Code für lediglich eine Version von Windows schreiben. Da jedoch alle zwei Jahre eine neue Hauptversion von Windows herauskommt, hätten diese Programme nur wenig Chancen gekauft zu werden. As John Walker, founder and CEO of Autodesk, Inc. stated it : "If you want to enter the Gates, you have to pay the Bill". Again and again, every year.

Bitte helfen Sie uns. Wenn Sie ein Problem mit RA haben, lesen sie die meistgestellten FRAGEN, und wenn wir Ihnen sagen, dass es sich um einen Windows Bug handelt, glauben Sie bitte nicht, dass wir das nur sagen, weil wir etwas gegen Microsoft haben. Es handelt sich um eine technische Tatsache und nicht etwa um eine faule Ausrede, die wir benutzen, wenn RA nicht plangemäss funktioniert. Ob man die Vorgehensweise von Microsoft nun billigt oder nicht, so muss man ihnen zumindest den Verdienst zuerkennen, dass sie die Computerindustrie einen grossen Schritt vorwärts getrieben haben. 

Wir bei TWD Industries versuchen lediglich die Welt besser zu machen - für jeden.