[Allegro] Windows 7

Do Feb 4 09:44:12 CET 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Liebe Frau Kapferer, Liebe Liste,

> da wir demnächst auf Windows 7 umsteigen, möchten wir anfragen, ob jemand
> schon Erfahrungen mit Allegro auf Windows 7 hat bzw. ob Allegro Version 29
> bereits Windows 7-konform ist.

"Konformitaet" im Sinne des Rechts ein bestimmtes Logo tragen zu duerfen,
gibt es m.W. nur fuer Geraetetreiber, die installiert allegro nicht.

Im Prinzip laeuft allegro unter XP, Windows Vista und Windows 7 gleich,
es gibt allerdings zwei Baustellen:

1. UAC (User Access Control), seit Vista standardmaessig aktiviert und die
   Tatsache, dass es die sogenannten "Hauptbenutzer" nun eher nicht mehr
   gibt (man kann die entsprechenden Rechte wohl noch vergeben, es wird
   aber darauf hingewiesen, dass das nur aus Kompatiblitaetsgruenden zu
   alten Versionen ermoeglicht wird).

Beides sind Versuche, die schaedliche Praxis einzudaemmen, dass alle mit
weitestgehenden Rechten fuer ihre lokalen Maschinen arbeiten: Ein Benutzer
soll mit "normalen" Rechten arbeiten, wenn er kurzzeitig administrative
Rechte benoetigt, wird er darauf hingewiesen und er muss das Administrator-
Password eingeben. Dann wird die kritische Aktion in einem eigenen Kontext
ausgefuehrt.

Fuer allegro sind hier folgende Bereiche betroffen:

* Installation mittels inst-all.exe erfordert zwingend Administratorrechte.
  (und wegen des erwaehnten anderen "Kontexts" sind also waehrend der
  Installation u.U. nicht dieselben Netzlaufwerke sichtbar / verbunden wie
  bei der normalen Arbeit: "Netzwerkinstallationen" benoetigen daher etwas
  mehr Geistesgegenwart des Administrators als vorher)

* Gewisse Programme werden bereits anhand ihres Namens als "Software-Installer"
  erkannt, dazu gehoert leider auch das 16bit UPDATE.EXE von allegro. Jeder
  Versuch, es zu starten wird also mit der Frage nach dem Administrator-Passwort
  quittiert, selbst wenn man dieses beibringt, hilft es i.A. nicht: UPDATE.EXE
  wird dann ja in anderem "Kontext" ausgefuehrt und sieht die Umgebungsvariablen
  nicht, evtl. auch nicht die Laufwerken mit den Daten, auf denen es operieren
  soll. Fuer 32- oder 64-bit-Programme gibt es die Moeglichkeit, beim
  Kompilieren in einem "Manifest" zu hinterlegen, dass es sich um keinen
  Installer handelt und dieses Programm nicht wuenscht, mit erweiterten Rechten
  ausgefuehrt zu werden, fuer 16bit-Programme gibt es m.W. keine Manifeste, hier
  greift nur die Namensheuristik.

  Nach meinen Erfahrungen vermeidet Umbenennen von UPDATE.EXE in ACUPD.EXE (und
  wie ich gehoert habe, trotz mehr als 8 Zeichen auch in REINDAMIT.EXE ;-) das
  Problem des unerwuenschten Aktivierens der UAC, Nachteil ist allerdings, dass
  alle vorhandenen Routinen, die "UPDATE" ausfuehren wollen, auf den neuen Namen
  anzupassen sind.

2. Die 2. Baustelle betrifft die 64bit-Versionen der Betriebssysteme: Die gab es
  schon fuer Windows XP und Windows Vista, mit Windows 7 und aktueller Hardware
  ist es aber sehr attraktiv und ich erwarte, dass noch in diesem Jahr eine
  grosse Anzahl von Neusystemen die 64bit-Version von Windows 7 einsetzen wird.
  Hat man die "Professional"-Variante oder "besser" (Enterprise, Ultimate und
  wie sie alle heissen), /sowie/ einen Prozessor mit Hardwareunterstuetzung fuer
  Virtualisierung, kann man kostenlos den "XP Mode" installieren, das ist ein
  Virtueller PC mit einer eigenen Lizenz von Windows XP (32 bit), damit sind
  aeltere Anwendungen dann lauffaehig, Uralt-Spiele jedoch eher nicht).

  "XP Mode" muss separat von Microsoft heruntergeladen werden (es handelt sich
  um ein ca. 450MB grosses Festplattenabbild), ich hatte anschliessend wenig
  Probleme, damit auf das Netzwerk zuzugreifen. Fuer lokale Datenbanken war
  es schon deutlich schwieriger. Fehlt die Hardware-Unterstuetzung fuer die
  Virtualisierung oder hat man eine Betriebssystem-Version, die fuer den
  "XP Mode" nicht berechtigt ist, so gibt es diverse Alternativen, dafuer
  muss man dann aber stets noch eine Extra-Lizenz fuer Windows XP besorgen...

  Am Vorhandensein der Umgebungsvariablen ProgramW6432 kann ein (32bit-)Programm
  recht zuverlaessig erkennen, ob es sich auf einer Windows64-Maschine befindet,
  das ein 32bit-Windows emuliert (und eine 16bit NTVDM nicht zur Verfuegung
  stellen koennen wird) [Microsoft-typischer Twist: Die 64bit-Programme wohnen
  in %windir%\System32, die 32bit-Programme in %windir%\SysWOW64 ;-)

Fuer allegro gilt:

- - Die beliebten TSRs und 16bit-Helfer aw.exe, ansi.com, fontload.com
  funktionieren nicht (sie werden in .bat-Dateien aufgerufen, auch in solchen,
  die durch Flexe zusammengebastelt werden, z.B. _as.flx und _rs.flx)

- - Keine Chance mehr fuer PRESTO.EXE und das Cockpit ACP.EXE

- - index.exe / qrix.exe wurden bereits 2008 auf eine 32bit-Version umgestellt und
  koennen als gruendlich getestet gelten. Beim Upgrade von alten Installationen
  auf Version 28 oder neuer muessen Aufrufe von INDEX.EXE allerdings
  umgearbeitet werden, manche Aufrufkonstruktionen aus den Fruehzeiten von
  allegro sind nicht mehr moeglich, ausserdem muss der qrix-Aufruf nun explizit
  erfolgen, index.exe stoesst ihn nicht mehr automatisch an.

- - eine 32bit-Version von import.exe als Ersatz (drop-in-replacement) des alten
  16bit-IMPORT.EXE wurde erst mit Version 29.12 (vom 23.12.09) ausgeliefert,
  allerletzte Kompatibilitaetsprobleme erst in den letzen zwei Wochen behoben,
  eine vorhandene Version 29 sollte also um die aktuellste verfuegbare
  Verison von import.exe angereichert werden, sofern man ein
  64bit-Betriebssystem hat.

- - fuer das Such- und Exportprogramm SRCH.EXE gibt es einen /theoretischen/
  Ersatz durch acon.exe zusammen mit srch.job: Die acon-Versionen seit etwa
  Dezember 2009 scheinen hier vergleichbare Resultate zu liefern. Selbst
  wenn man srch.job noch etwas umbaut (einen zweiten Schalter -e ermoeglichen,
  Datenbank anhand von -d suchen, wenn -b fehlt) scheint es mir allerdings
  nicht moeglich, vorhandene Aufrufe von SRCH.EXE rein mechanisch auf acon-
  Aufrufe umzubauen.
  Ich moechte die Entwicklungsabteilung bitten, ein 32bit srch.exe bereit-
  zustellen, das kann meinetwegen auch nur ein "Stub" sein, das die
  Kommandozeile fuer acon geeignet umbaut und dann weiterleitet. Jedenfalls
  wird m.E. analog index und import ein Drop-In-Replacement benoetigt:

- - fuer das 16bit-UPDATE.EXE gibt es analog SRCH.EXE den theoretischen Ersatz
  durch acon.exe zusammen mit update.job, d.h. vorhandene Aufrufe muessen
  umgeschrieben werden von jemandem, der sich mit allegro auskennt. Bei
  komplexen Update-Vorgaengen (mit Schalter -e fuer Manipulationen an
  Datensaetzen beim Einmischen) reicht das aber nicht aus, auch die benutzte
  Parameterdatei muss umgeschrieben werden, mangels einer Konvention dafuer
  in update.job weiss man noch nicht einmal, wie sie umzuschreiben ist bzw.
  muss Parameterdatei plus update.job konzertiert umschreiben. Das ist
  definitiv nichts fuer Anwender oder System-administratoren.
  Ein 32bit-Update.exe mit der gewohnten Funktionalitaet sollte m.W. unbedingt
  bereitgestellt werden, das sollte eigentlich auch die bei 1. beschriebenen
  und auch fuer Anwender der 32bit-Betriebssysteme auftretenden Probleme mit UAC
  in den Griff bekommen.

Fazit: Auch aeltere, moeglicherweise alte und sehr alte Versionen von allegro
duerften unter den /32bit-Versionen/ aller Microsoft-Betriebsysteme lauffaehig
sein, insbesondere, wenn man mit a99 arbeitet. Unter Vista und Windows 7 mit
UAC (wie erwaehnt der Standard) muss man Aufrufe von UPDATE.EXE derzeit auf
einen "ungefaehrlichen Namen" umstricken, betroffen sind aber nur manche
Formen der Fremddatenuebernahme. Handlungsbedarf fuer die Entwicklungsabteilung
sehe ich als gegeben: Anwender haben Vista weitestgehend uebersprungen, wg.
Wirtschaftskrise im letzten Jahr Investitionen aufgeschoben, d.h. bereits fuer
dieses Jahr ist zu erwarten, dass eine grosse Zahl von Anwendern auf neue
Maschinen mit Windows 7 umsteigen wird. (Institutionelle Anwender beschaffen
gerne Systeme mit aktuellen Lizenzen, die dann aber bereits werksseitig auf
aeltere Versionen des Betriebssystems gedowngradet sind, auch wenn auf diese Art
bereits Vista "uebersprungen" wurde, wird es nicht ewig so weitergehen)

Unter den 64bit-Versionen der Betriebssysteme ist seit Einfuehrung von a99
die Katalogisierungsfunktion gewaehrleistet, seit Version 28 auch die
Reindexierung der Datenbanken. Im- und Export von Daten ist aber stark
beeintraechtigt, hier muss die Entwicklungsabteilung dringend etwas tun,
vorzugsweise durch Bereitstellung der noch fehlenden Drop-In-Replacements
fuer SRCH.EXE und UPDATE.EXE, hilfsweise und ergaenzend durch weitere
Kompatiblisierung von srch.job und update.job (vermutlich auch Spendieren
des oft diskutierten Schalters "-j" fuer acon.exe) sowie Unterstuetzung
fuer GM-Konventionen in update.job.

Weil wie erwaehnt nicht nur bezogen auf die Software, sondern auch auf
die Hardware fuer dieses Jahr zu erwarten ist, dass ein Modernisierungs-
stau bei den Anwendern aufgeloest wird, gehe ich davon aus, dass eine
nennenswerte Zahl von Anwendern in den naechsten Monaten auf 64bit-
Betriebssysteme umsteigen wird. Von XP kennen wir, dass kleinere
Institutionen gerne die 10 Euro pro Arbeitsplatz einsparen, die die
"professional"-Variante kosten wuerde, oder darauf verzichten, den
Monster-Download fuer XP-Mode durchzufuehren, oder die Konfiguration
des virtuellen PCs nicht in den Griff bekommen, "XP Mode" mit der Emlulation
eines 32bit-Windows-XP kann also definitiv nicht vorausgesetzt werden.
Auch hier besteht also dringender Handlungsbedarf, allegro auf 64bit-Systemen
komplett mit allen Komponenten lauffaehig zu machen.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAktqiNwACgkQYhMlmJ6W47PeGgQAlf7+0aAZ6zbGUjMZVemrsMjM
LL+8hKP7+RyNuDWgacB3WFDLs2+THNlb03pqB/yra+fWNKhXttF82XA9j8nTvAG/
WMwzpimpG5hwO9i1VYjnY9zQ1P7pPkzajEDwT70R5SS2oYqNMNl1eL2Edin/2iPQ
qXu89Zr/BLNglmon84I=
=+ZHY
-----END PGP SIGNATURE-----