[Projekt] Mein STL-Viewer

[Schrompf]

Ich find's beeindruckend.

[Psycho]

Prima!
Warum die Begrenzung auf 4 Dateien?

[Krishty]

Warum die Begrenzung auf 4 Dateien?

Kurz gesagt: Weil’s noch im Prototypen-Stadium ist :D

• Spart Code für Memory Allocation
• Ich habe nicht den geringsten Plan, wie ich mehr als vier Schaltflächen zur Farbauswahl in der UI anordnen soll (ich kann ja schlecht hundert Buttons reinklatschen)

Ich spiele mit dem Gedanken, das Material im Tree View neben der Datei anzuzeigen. Damit wäre die Farbauswahl endlos skalierbar. Leider sind die Schaltflächen in Tree Views immer so winzig; das beeinträchtigt vielleicht die Handhabbarkeit … ich werde am Wochenende ein Bisschen testen.

[Chromanoid]

Vielleicht ein Panel mit Farbtopf, Thumbnail und Baumansicht pro Datei?

[Add new file]
______________________
-frog01.stl--[Ø][-][X]
____________
|
| Thumbnail
|____________

[COLOR]

[o]File
|-[o]Object
______________________
-frog02.stl--[Ø][-][X]
____________
|
| Thumbnail
|____________

[COLOR]

[o]File
|-[o]Object
______________________

[Krishty]

Kleines Update: Ich zeichne nun Rückseiten von Polygonen. (Hier muss ich das zum Glück weniger ausführlich erklären als anderswo :D Ich muss das echt verpeilt haben; es gibt eigentlich keinen Grund, es nicht zu tun.)

Download wie immer unter https://papas-best.com/stlviewer_de

Virustotal sagt, dass mir dieses Mal alle Schlangenölprogramme außer Qihoo360 und Webroot aus dem Weg gehen. Trotzdem hat sich direkt jemand beschwert, dass Avira meckern würde. False Positive Report ist abgeschickt.

Kurze technische Erläuterung: Das große Problem bei doppelseitigem Zeichnen ist, dass man auf der Rückseite auch die Normale invertieren muss, sonst ist die Beleuchtung falsch. Zum Glück hat Direct3D bool SV_IsFrontFace als Pixel Shader-Parameter. Theoretisch müsste das zu einem Shift und einem XOR kompilieren. Praktisch muss ich das erst noch herausfinden. (Gibt es dafür gute Tools? Den AMD GPU Shader Analyzer hat man ja leider nicht fortgeführt. Mann war der gut für sowas …)

Chromanoid, dir zu antworten steht noch immer auf meiner TODO.

[lolumad]

Warum stellst du den Sourcecode nicht zur Verfügung? :shock:

[Krishty]

Warum stellst du den Sourcecode nicht zur Verfügung? :shock:

Tue ich doch:

Hast Du Überlegungen, den Quelltext ebenfalls zu veröffentlichen?

Klar – wer interessiert ist, kann sich melden und kriegt eine PM :)

Warum so? Weil’s Arbeit ist, so einfach ;)

Edit:
Gelöschte Datei
Erfordert Visual Studio 2017. Falls du die verteilte EXE 1:1 rekonstruieren möchtest, musst du zusätzlich dieses CFF-Explorer-Skript nutzen und die Systemuhr auf Sonntag, 17:58 zurückdrehen.

[Krishty]

Sehr geil! Startet auch unter Linux64/Wine problemlos und lädt die Files echt flott.

Könntest du bitte nochmal die aktuelle Version testen? Jemand beschwert sich, dass sie auf seinem Linux/Wine nicht funktioniert … was hattest du denn genutzt – die portable Version oder den Installer?

[Biolunar]

Sehr geil! Startet auch unter Linux64/Wine problemlos und lädt die Files echt flott.

Könntest du bitte nochmal die aktuelle Version testen? Jemand beschwert sich, dass sie auf seinem Linux/Wine nicht funktioniert … was hattest du denn genutzt – die portable Version oder den Installer?

Ich habe die portablen x86_64 und die x86 mit den default Wine profilen für Win7 und Win10 getestet und konnte keine Probleme feststellen.

[Krishty]

Super; ich danke dir vielmals dafür!

[Krishty]

Neue Version, aber ohne neue Features. Dafür umso mehr für ZFX – ich habe ein Bisschen Technische Schuld aufgeholt:


Versionierung überarbeitet

Ich wollte die Versionierung immer so einfach wie möglich halten, und habe sie deshalb im Quelltext mit __DATE__ und __TIME__ gemacht und im Setup von Hand. Das hat Nachteile:

1. … „von Hand“.
2. Builds sind nicht reproduzierbar, weil man immer mit anderem Datum kompiliert.
3. __DATE__ und __TIME__ sind lokale Zeit statt UTC. Das ist recht verwirrend, vor allem mit dem Dateidatum.
4. Ich möchte demnächst z.B. zwei Viewer in einem Setup kombinieren, und das geht damit nicht.
5. Ich konnte bisher nur alle Projekte auf einmal deployen, nicht einzeln. Unsinn!

Also musste das mal ausgemistet werden.

Die Versionsnummern werden nun automatisch erzeugt, in UTC. Einfaches Batch-Skript. Die überflüssigen Nullen sind raus. (18.5.19 statt 18.05.19).

Ich habe gelernt, dass man WiX Umgebungsvariablen übergeben kann. Im Setup-Skript also SET WIX_PAPA_STLVIEWER_VERSION=… und im WiX-Skript Version='$(env.WIX_PAPA_STLTHUMBNAILS_VERSION)'. Nichts mehr händisch. Fuck yea.

Ich habe gelernt, dass man dem CFF Explorer Parameter für seine Skripte übergeben kann, indem man sie in die Kommandozeile hinter den Skriptnamen schreibt. Nun habe ich nur noch ein Skript zum Säubern aller EXEs/DLLs statt eines pro Datei. Fuck yea.


Neue WiX-Version.

WiX ist furchtbar zu nutzen, aber trotz allen Jammerns habe ich gerade keine Zeit, das Deployment auf was anderes umzusatteln. Also mache ich erstmal das Beste draus und halte es aktuell.

WiX hatte ein Sicherheitsproblem. Soweit ich das sehe, waren aber keine Setups betroffen, sondern nur Entwicklerrechner. Nagut. Neue Version, alles kompiliert noch, nichts ist größer geworden.


Neue Visual Studio-Version

Der Umstieg auf 2017.7 barg eine gute und eine schlechte Überraschung. Die gute war, dass Funktionsenden und if-Blöcke besser optimiert werden – solider Win in der Größe des Viewers.

Die schlechte war, dass eine Optimierung mit memcmp() weniger stark durchgeführt wird – solider Verlust in der Größe.

Unter’m Strich war der selbe Code fast ein KiB größer. Ich konnt’s aber mit anderen Änderungen ausbügeln:


Keine Microsoft-Header mehr

Ich habe noch an genau einer Stelle externe Header aus dem Windows SDK benutzt: Wenn ich benachbarte Dateien in einem Verzeichnis aufzähle, damit man mit den Pfeiltasten durchspringen kann.

Diesen Code wollte ich schon lange isolieren, aber es ist so eine richtig blöde Pfriemelarbeit. Ich nutze um die zehn COM-Interfaces der Windows-Shell, und muss jede einzelne Deklaration abkopieren, überarbeiten, und prüfen. Das hatte ich nun zwei Jahre vor mir hergeschoben. Hauptgrund: VARIANT. Guckt euch die Struktur an, sonst glaubt ihr es nicht. Die Kompatibilitäts-Workarounds. Die unions. Die structs mit und ohne Namen. Das nachzubauen war die Hölle.

Nun sind’s 1000 Zeilen eigener Code statt 300 Zeilen + Windows-, COM-, und Shell-Header. Die Kompilierzeit ist von „langsamste Datei des Projekts“ zu „nicht mehr messbar“ gesprungen.

Ich habe dabei gemerkt, dass ich einen String umständlich kopiert habe (StrRetToStr()), wo COM ihn direkt ausgeben kann (StrRetToBuf()). Ist nun etwas schneller, Fehlerbehandlung ist entfallen und der Viewer braucht einen COM-Import weniger. Größe geschrumpft.

An einer anderen Stelle hatte ich noch __uuidof() benutzt, statt händisch die UID der Schnittstelle anzugeben. Als ich das entfernt habe, ist die Größe geschrumpft. Ich hab’s nicht kontrolliert, aber Visual Studio scheint die UIDs nicht zu mergen, wenn sie durch Spracherweiterungen an COM-Deklarationen gebunden wurden. Wieder was gespart (und zusätzlich standardkonform geworden).

Dann habe ich von Hand Funktionen geinlinet, die nur einmal aufgerufen werden. Visual Studio sollte das seit 2017.6 angeblich von selber können, aber ich hab’s noch nie erlebt. Wieder 250 unnütze Bytes zurückgewonnen. Nun ist die neue Version kompakter als die vorherige.

Meine PDBs sind übrigens mit Verbannung der MS-Header satte 15 % kleiner geworden …

[Jonathan]

Habs nur ganz kurz angesehen, aber da du nach Verbesserungsvorschlägen gefragt hast: Es gibt keine Drag'n'Drop Unterstützung? Mein normaler Workflow sieht so aus, dass ich ein Explorerfenster mit meinem Projekt offen haben, ein Programm über eine Verknüpfung zu starten und das Modell ins Fenster zu ziehen mache ich da wahnsinnig gerne, weil es viel schneller ist, als über den Öffnen-Dialog erst mühsam zum richtigen Ordner zu navigieren.

[antisteo]

Ja; ich wurde gerade eben gefragt, noch andere Programme zu testen. Darunter fstl, den „fastest STL Viewer“. Der ist tatsächlich *viel* schneller als die anderen Programme (ich habe meine Seite entsprechend aktualisiert), braucht für Binärdateien aber noch fast doppelt so lang wie ich.

Für ASCII-Dateien braucht er sogar 10-Mal so lang. Da sind die meisten anderen Programme sowieso fast um den Faktor 100 langsamer als ich; aber das kann ich ja nicht hinschreiben, glaubt mir doch keiner …

Geschlagen werde ich im RAM-Verbrauch. Das liegt zum einen daran, dass ich Farben unterstütze (fstl & Co nicht) und zum anderen daran, dass ich die Normalenvektoren aus der Datei verwende, statt sie im Geometry Shader neu zu berechnen, weil ich halt zeigen möchte, wie die Datei ist statt wie sie sein sollte. (Das ist hoffentlich eine ausreichende Entschuldigung, aber ich schaue mal, ob ich’s irgendwann optimiert kriege.)

Hoffentlich bringst du bald einen eigenen Compiler heraus, der auch ohne manuelles Herumwurschteln "Aufgaben" in Maschinencode zu übersetzen kann, die nicht irgendwelchen strukturellen Overhead haben.

[Krishty]

Habs nur ganz kurz angesehen, aber da du nach Verbesserungsvorschlägen gefragt hast: Es gibt keine Drag'n'Drop Unterstützung? Mein normaler Workflow sieht so aus, dass ich ein Explorerfenster mit meinem Projekt offen haben, ein Programm über eine Verknüpfung zu starten und das Modell ins Fenster zu ziehen mache ich da wahnsinnig gerne, weil es viel schneller ist, als über den Öffnen-Dialog erst mühsam zum richtigen Ordner zu navigieren.

Verdammt, du hast recht. Ich bin normalerweise auch totaler Drag’n’Drop-Fan, aber die Abhängigkeitshölle (da hängen COM-Schnittstellen dran) war mir kurzfristig zu aufwendig zu wrappen und dann hab ich’s vergessen. Ist nun wieder auf der To-do.

[Krishty]

Drag & Drop ist drin (erstmal nur für einzelne Dateien): https://papas-best.com/stlviewer_de

• Die „neue“ Windows-NT-Schnittstelle (IDropTarget) ist wirklich höllisch kompliziert und unheimlich schwer nutzbar. Ich bin fast dran verzweifelt und nutze stattdessen …
• … die alte Win-3.1-Schnittstelle (WM_DROPFILES). Ist viel einfacher und kompakter. Man kann halt nur nichts filtern, nicht den Cursor ändern, oder COM-Objekte wie Streams ablegen.
• Das Feature ist mit 168 B zu buche geschlagen. Wenn ich statt dem WS_EX_ACCEPTFILES-Stil explizit DragAcceptFiles() aufrufen würde, wären es nochmal 36 B mehr – darum immer alles schön statisch in die Templates kompilieren!

Als weitere Verbesserung rotiert nun die Lichtquelle mit dem Betrachter mit; es gibt also keine schattigen Stellen mehr. (Der Wunsch kam via E-Mail.)

[Jonathan]

joah, tut ganz gut :)

[Krishty]

Wieder eine neue Version:

https://papas-best.com/stlviewer_en#download

Mit Bugfix und verbessertem Antialiasing.


Hintergrund und eine Empfehlung für D3D-Programmierer:

Ein User hat sich bei mir gemeldet, weil der Viewer abstürzt. Er hat mir seinen Crash Dump gesendet, und der sah erstmal recht merkwürdig aus – D3D war zu zwei Dritteln initialisiert, aber die Objekte waren total kaputt.

Das war die Folge von drei kleinen Fehlern:

• Ich habe blind Antialiasing auf 4× gestellt. Schließlich garantiert D3D ab 10.1, dass jede GPU mindestens 4× unterstützt! Nur habe ich vor geraumer Zeit die Hardware-Anforderungen auf 10.0 gesenkt … und tadaaa, da ist Antialiasing komplett optional. Der User hatte nur 10.0.
• Die Swap Chain ließ sich problemlos mit 4×MSAA erstellen. Der Depth Buffer jedoch nicht. (WTF?! Komischer Treiber, aber … ist halt erlaubt.)
• Dafür hatte ich Fehlerbehandlung, aber die enthielt einen Flüchtigkeitsfehler beim Setzen eines Zeigers. Dadurch funktionierte sie nur einmal. Mein Viewer beginnt sofort beim Start in einem separaten Thread mit dem Laden von D3D, weil das so ewig lange dauert (erster Versuch, hinterlässt kaputten Zeiger) und beim Laden einer Datei dann nochmal (zweiter Versuch erwischt kaputten Zeiger). Crash.
• Der Treiber unterstützt nur 32 MiB VRAM, obwohl D3D 10 garantierten Platz von 128 MiB pro Ressource vorschreibt. Das hat zwar nichts zum Absturz gebracht, aber es führt dazu, dass der User auch nach der Korrektur nur mini-STLs öffnen kann.

Daher meine Empfehlung an D3D-Programmierer: Sucht das höchste unterstützte Multisample-Level (ID3D11Device::CheckMultisampleQualityLevels()) und nutzt das. Dann macht Legacy-Hardware keine Probleme und neue GPUs profitieren von besserem MSAA (mittlerweile scheint jeder 8× zu unterstützen, obwohl D3D nur 4× garantiert). Das macht mein Viewer nun auch. (Ich weiß nur noch nicht, wie ich es in meinen anderen Programmen mit Coverage-Based Texture Transparency kombiniere, ohne vier verschiedene Shader zu schreiben.)

Kosten: ca. 140 B.

[Krishty]

Willkommen zu den langweiligsten Showroom-Screenshots auf ZFX ever!

Die letzten zehn Wochen habe ich das Setup überarbeitet (mein MSI-Thread spricht Bände) um von einem WiX-basierten Setup wegzukommen und meine Setups selber zu bauen. Warum ich das wollte?

• Bloat. Die Setups sind nun von 220 KiB auf 72 KiB geschrumpft. Für einen 60 KiB kleinen Viewer sollte die Setup-Größe überhaupt nicht dreistellig sein!
• Mehr Anpassungsmöglichkeiten. Das erkläre ich aber in der Bilderstrecke unten.
• Weniger Abhängigkeiten zu pflegen. Statt eines 120 MiB großen WiX-Downloads inklusive .NET-Framework habe ich jetzt 3000 Zeilen eigenen Code, die quasi das gleiche machen.
• Build-Speed. WiX hat zehn Sekunden zum Bauen des Setups gebraucht; mein eigenes Tool ist rund hundert Mal schneller. Scheiß XML, scheiß .NET, scheiß WiX.
• Ich wollte verdammt nochmal verstehen, wie ein Setup überhaupt funktioniert.

Das Ergebnis könnt ihr unter https://papas-best.com/stlviewer_en#download herunterladen. Ich bitte euch auch drum, das zu tun! Falls ich was verbockt habe, erreicht ihr mich ja am schnellsten :) Außerdem vertraut ihr mir und verkriecht euch nicht sofort unter ’nem Stein wenn euch SmartScreen meldet, die Datei wäre unbekannt und potentiell gefährlich.

Übrigens geht das Setup nun ohne Admin-Rechte – es sei denn, ihr habt bereits eine alte Version installiert. Dann braucht es ein Mal Admin-Rechte, um die alte Version zu aktualisieren. Bei zukünftigen Updates aber nicht mehr.


Vorher-Nachher

Erstinstallation

Das erste, was der Anwender vom Programm sieht. Früher:

Oh Gott wie hässlich.

• Die freie Spalte links ist, weil man da sein Logo platzieren soll. Ich will aber kein Logo platzieren! Und WiX unterstützt nichts anderes. Darum ist der Platz halt ungenutzt.
• Beachtet, dass das Setup als Schriftart Tahoma nutzt und die EULA in Calibri, weil das halt die Standardschriftarten in WiX und Rich Text sind. Die Standardschriftart in Windows ist aber Segoe UI (Titelleiste!), also mischen wir da drei Schriftarten. WTF.
• Die Knöpfe sind zu klein für den Windows-Standard. (Folge der falschen Schriftart.)
• Der Print-Knopf verbraucht 70 KiB, weil ein WiX-Plugin dahintersteckt. Und man kriegt ihn nicht ohne riesen Aufwand weg. Kann man sich nicht ausdenken.
• Wenn man Back nicht benutzen kann, warum ist es überhaupt da? (Protip: Weil die WiX-Programmierer faul sind.)
• Warum eine Checkbox für Accept und ein separater Knopf zum Installieren?! Warum nicht beides auf einen Knopf?! (Machen Visual Studio & Co auch seit Jahren so.)
• Im Header des Fortschrittsfensters habe ich mir dann ein Bisschen Branding erlaubt, aber … wenn wir mal ehrlich sind, ist das doch scheiße. Weg damit.
• Abschlussfenster: Wieder die linke Spalte verschwendet.
• Warum eine Checkbox, um das Programm zu starten? Warum kein Knopf? Protip: Weil WiX es nicht anders kann. Fun Fact: Es kann auch keinen transparenten Hintergrund für die Checkbox; ein Hintergrundbild könnt ihr also auch vergessen.

Jetzt:

• Endlich mal konsistente Schriftarten und ordentliches Layout. (Entspricht ungefähr dem Visual Studio- und Office-Setup.)
• Die Großschreibung in der MIT-Lizenz könnt ihr weglassen – es geht darum, dass der Haftungsausschluss nach amerikanischem Recht direkt erkennbar sein muss. Großschreibung ist Mittel der Wahl, aber bei kurzen Lizenzen geht es auch ohne. Und jetzt passt das Ding endlich mal komplett auf den Bildschirm!
• Ich wollte eigentlich eine Klausel hinzufügen, die militärischen Einsatz verbietet – vergessen. Nächstes Mal.
• Die Fortschrittsleiste verdeckt teilweise den Statustext. Fiel mir ohne Schnappschuss nie auf; ich behebe das für die nächste Version.
• Launch startet das Programm. Wer das nicht will, kann ja X benutzen. Aber ich behaupte mal, dass das Verhältnis 9:1 und die Zeitersparnis für die Masse groß ist. (Visual Studio macht’s übrigens auch so.)

Updates
Wahrscheinlich noch häufiger als Erstinstallationen sind Updates. Da habe ich früher einfach das selbe Update nochmal abgespult, inklusive EULA-Zustimmung. Hat User verwirrt, weil ich ein Update ankündige und sie eine Installation kriegen. „Muss ich die alte Version vorher deinstallieren?“ – berechtigte Frage. WiX kann zwar Upgrades erkennen, aber das war mir zu aufwändig.

Nun blende ich direkt einen Update-Bildschirm ein. Samt Changelog, damit die Nutzer nicht denken, ich würde neue Versionen nach Lust und Laune verteilen:

Deinstallation

Die größte Pest war bisher das Deinstallieren. WiX führt einen durch fünf(!) Fenster durch. LIEBER GOTT, LASS ES ENDLICH VORÜBER SEIN. Hat überhaupt jemals irgendjemand alle diese Textwände gelesen?!

Jetzt geht das ruck, zuck:

uninstall_n.png (6.6 KiB) 7206 mal betrachtet

So. Leider keine aufregenden Sachen heute, sondern nur das. Die kleinen Fehler, die mir beim Anfertigen der Screenshots aufgefallen sind, behebe ich für die nächste Version. Ich bin einfach nur froh, dass ein zehnwöchiger Alptraum zuendegeht und warte auf Feedback …


Übrigens ist nicht alles WiX’s Schuld. Die haben auch eine neue, modernere UI in ihrem Burn-Bootstrapper. Aber damit kriegt ihr Bloat im Megabyte-Bereich.

[xq]

Ich finds gut, dass du dir auch über sowas Gedanken machst. Hut ab und Daumen hoch!

[Psycho]

Ich mag ja Deine Detailverliebtheit und den Verzicht auf Bloat.

Aber ein eigener Installer..uiuiui. Das Ding einmal zu schreiben, ok. Das es auf allen möglichen Systemen so funktioniert wie es soll, schwer zu testen. Und dann das Maintainen..aber wirst schon wissen, was Du machst.

In welchen Ordner installiert sich der Viewer denn, wenn es ohne Admin-Rechte geht?

[Krishty]

Meine MSI ist ja „nur“ die Schnittstelle zum Windows Installer-Dienst, der dann dafür sorgt, dass es auf allen möglichen Systemen so funktioniert wie es soll. Orca bietet auch eine umfassende Validierung der Pakete.

Eine Auflistung, was mit und ohne Admin-Rechte wo landet, hast du hier: https://docs.microsoft.com/en-us/window ... on-context

Du meist wohl unter Folder Redirection das ProgramFilesFolder; das liegt bei mir unter A:\Users\Krishty\AppData\Local\Programs. Darunter dann noch ein Unterordner Papa’s Best\STL Viewer. Hier übrigens schon ein Problem: Weil da kein x86 oder x64 im Namen ist, können die Installationen unterschiedlicher Plattformen in Konflikt kommen … wird aber noch behoben.

[Psycho]

Oh, ich verstehe. In dem Fall nehme ich jegliche Kritik zurück. ;) Gut gemacht.

[marcgfx]

Ich finds cool Krishty. Du zeigst wie viel Potential verschwendet wird. Wie viel besser Software sein könnte. Wir bauen immer schnellere Geräte aber verschwenden diese Leistungssteigerung durch ineffizients.

[Tiles]

Schwieriges Kapitel. Denn diese Effizienz will ja auch erst mal erarbeitet sein. Und das kostet eben Manpower. Und wieso sollte man Manpower in was investieren was schon geht? Das rechnet sich für die allermeisten Entwickler nicht.

[xq]

Schwieriges Kapitel. [...] Und wieso sollte man Manpower in was investieren was schon geht? Das rechnet sich für die allermeisten Entwickler nicht.

Ja, ich denke, das hier das Problem in "Gute Performance ist kein Qualitätsmerkmal" liegt. Mich regt das in den letzten Jahren auch auf, dass immer mehr Leute einfach "Node+Chromium" nehmen und sagen: "das ist jetzt mein framework, weil das kann ich als webprogrammierer und darum nehm ich das jetzt". Aber: ich schweife ab, das passt wie immer mehr in den jammerthread (können ja da gerne weiterdiskutieren)


Zu Krishty: Thumbs up für die ganze Sache mit MSI, der Installer läuft auch mit Wine hervorragend und schön schnell :)

[Krishty]

Zu Krishty: Thumbs up für die ganze Sache mit MSI, der Installer läuft auch mit Wine hervorragend und schön schnell :)

Boah vielen Dank, das beruhigt mich mega!

[Chromanoid]

Voll cool, ich installiere nachher mal :) schon mal daran gedacht ein package bei http://chocolatey.org bereitzustellen?

[scheichs]

Ja das Setup ist wirklich blitzschnell und gab keine Probleme (Win 10 x64 - October Build). Hab jetzt auch Deinen MSI-Thread gesehen. Klasse gemacht!

[Krishty]

Danke, danke!

Aber das Ausschlaggebende für das Setup war nicht die Leistung, sondern das Vertrauen. Ich gebe WiX ein 60 KiB großes Programm und bekomme ein 224 KiB großes Setup zurück. Warum das so groß ist und was das macht? Keine Ahnung. Da liegt auch eine DLL drin, die größer ist, als mein Viewer. Was die tut? Weiß niemand. Versucht, doch mal das herauszufinden! (WiX ist Open Source, kann doch nicht schwer sein – am Arsch.)

Und nun soll ich dieses viel zu große Paket, über das ich nichts weiß, den Usern zur Ausführung mit Admin-Rechten geben.

Niemals. Da schreibe ich doch lieber alles selber. Beim neuen Paket kann ich zu ~80 % den Zweck des Inhalts nachvollziehen, und am Rest arbeite ich noch.

[Psycho]

In meiner VM ist der Text leider etwas abgeschnitten und ich muss scrollen:

Win7 classic theme