Windows 10: Desktop App-Converter macht Win32- zu Universal-Apps

[sh17]

Noch was neues

http://winfuture.de/news,91668.html

[Bernhard Geyer]

Und was sind die Voraussetzungen? Vermutlich ein mit VS.NET Entwickeltes C#/VB.NET-Programm.

[mkinzler]

Heute sollte man besonderst vorsichtig sein.

[sh17]

Ne, die Meldung ist schon vom 30.3.

http://techcrunch.com/2016/03/30/desktop-app-converter/


https://devpreviewsignup.windows.com/
https://developer.microsoft.com/de-d...ridges/desktop

[mquadrat]

Die Session dazu kann man sich auf Channel 9 anschauen. https://channel9.msdn.com/Events/Build/2016/P504 Dort konvertieren sie VLC. Sollte mit jedem Win32/64 Programm gehen.

[bra]

Das ist schon seit Monaten bekannt, dass sowas kommen soll.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1334388)

Und was sind die Voraussetzungen? Vermutlich ein mit VS.NET Entwickeltes C#/VB.NET-Programm.

Es sollen wohl alle möglichen Win32-Anwendungen und auch Installer unterstützt werden. Allerdings ist mir noch unklar, wie das mit den Installern dann aussieht, wenn man kein MSI hat (wie bei uns der Fall).

[Uwe Raabe]

Zitat:

Zitat von bra (Beitrag 1334402)

Es sollen wohl alle möglichen Win32-Anwendungen und auch Installer unterstützt werden. Allerdings ist mir noch unklar, wie das mit den Installern dann aussieht, wenn man kein MSI hat (wie bei uns der Fall).

In dem Video wurde galube ich erwähnt, daß es vollkommen egal ist, wie installiert wird (MSI, Exe, Batch, ...). Die Installation erfolgt in einem Docker-Container und man schaut, was da alles so gemacht wird.

[Der schöne Günther]

Ja, die Angabe auf WinFuture ist falsch. Es kann "installiert" werden wie man mag, meinetwegen über ein Batch-File.

Was ich bislang gelernt habe:

• Der Entwickler installiert einmalig seine Anwendung in einen Docker-Container. Daraus wird dann ein .appx-Paket gemacht
• Managed oder unmanaged, .NET oder Delphi. Egal. Alles geht.
• Wenn die Anwendung nun z.B. etwas in der Registry in HKCU schreiben will, wird das umgeleitet. In den eigenen Ordner dieser Anwendung. Dieser Registry-Hive wird erst geladen wenn man die App startet. Vorteil: Kein Registry-Bloat mehr. Und die Anwendung lässt sich komplett rückstandslos entfernen
• Ebenso im Dateisystem: Aufrufe wie CreateFile(..) funktionieren angeblich selbst wieder in C:\Programme oder im Windows-Verzeichnis. Sie funktionieren. Aber das Windows-Verzeichnis wird nicht verändert. Nur der umgeleitete ("vorgegaukelte") Ordner für diese Anwendung
• Die Anwendungen selber sind nicht gesandboxed sondern laufen "Full Trust". Hier musste man sich entscheiden: Tut man den Nutzern einen Gefallen oder den Entwicklern? Es wurden die Entwickler. Wenn ich das richtig verstehe bedeutet das auch dass ich theoretisch eine Keylogger oder Ransomware-"App" schreiben könnte. Hoffentlich kann man sich hier freiwillig einschränken.
• Richtig interessant wird es mit dem Zugriff von Win32-Anwendungen auf neue Dinge wie Live Tiles, Push-Benachrichtigungen, das Info-Center oder Background-Tasks. Das soll alles möglich sein. In der "App" wird neben der Win32-Anwendung noch eine zweite UWP-App als Schnittstelle laufen. Die beiden können sich gegenseitig starten und miteinander reden. Klicke ich beispielsweise auf eine Stunden alte Benachrichtigung im Info-Center, startet die UWP-App meine richtige Win32-Anwendung. Siehe Bild im Anhang.
• Microsoft hätte natürlich gerne dass man mit seiner Win32-Anwendung ohne Code zu ändern am Start sein kann. Aber am Ball bleibt und Bestandteile seiner Win32-Anwendung immer weiter in die UWP-App umziehen lässt. Denn wenn alles umgezogen ist könne man die Anwendung auch auf einer XBox, einem Raspberry oder sonstwas laufen lassen. Wer mag...

Ich finde das wahnsinnig interessant.

Aus Nutzersicht vor allem das reibungslose Installieren/Deinstallieren. Mama braucht dann auf ihrem PC auch kein Adminkonto mehr.

Aus Entwicklersicht vor allem die Möglichkeit eine 1:1 bestehende Anwendung mit "RT"-Features zu erweitern.

[Bambini]

Die wenigsten Anwendungen sind für Windows 10 alleine, die universial App werden auch niemals auf Windows Phone laufen können.
Ich sehe da keinerlei Mehrwert für die Anwendung.

[Bambini]

Zitat:

Zitat von Der schöne Günther (Beitrag 1334410)

Aus Nutzersicht vor allem das reibungslose Installieren/Deinstallieren. Mama braucht dann auf ihrem PC auch kein Adminkonto mehr.

Wenn es mit dem Sandboxing dann doch nicht ganz so klappt, wie sollte man so etwas in Delphi debuggen?

[Der schöne Günther]

Ich verstehe nicht was du meinst. :gruebel:

"Debuggen" ist für mich etwas, das ich während der Entwicklung auf meinem Rechner mache. "Sandboxing" ist für mich das Beschränken/Isolieren einer Anwendung auf dem Zielsystem.


Edit:
Oder meinst du das "Umlenken" wenn ich beispielsweise in meiner Delphi-Anwendung eine Datei C:\log.txt anlegen will und das wird umgeleitet auf, keine Ahnung, %appdata%\MyApp\C\log.txt? Die Aussage war dass die Anwendung davon nichts mitbekommt, dass sich alles verhält wie gehabt. Das System greift natürlich nicht wenn ich im RAD Studio F9 drücke. Gute Frage wie man das simulieren könnte...

[Uwe Raabe]

Zitat:

Zitat von Bambini (Beitrag 1334411)

Die wenigsten Anwendungen sind für Windows 10 alleine, die universial App werden auch niemals auf Windows Phone laufen können.
Ich sehe da keinerlei Mehrwert für die Anwendung.

Die Anwendung selbst bleibt ja weiterhin als Win32-App auf anderen Systemen lauffähig und kann dort wie bisher installiert werden. Durch den Konverter macht man es halt zusätzlich noch Windows 10 alike.

[Bambini]

Zitat:

Zitat von Der schöne Günther (Beitrag 1334414)

Ich verstehe nicht was du meinst. :gruebel:

"Debuggen" ist für mich etwas, das ich während der Entwicklung auf meinem Rechner mache. "Sandboxing" ist für mich das Beschränken/Isolieren einer Anwendung auf dem Zielsystem.


Edit:
Oder meinst du das "Umlenken" wenn ich beispielsweise in meiner Delphi-Anwendung eine Datei C:\log.txt anlegen will und das wird umgeleitet auf, keine Ahnung, %appdata%\MyApp\C\log.txt? Die Aussage war dass die Anwendung davon nichts mitbekommt, dass sich alles verhält wie gehabt. Das System greift natürlich nicht wenn ich im RAD Studio F9 drücke. Gute Frage wie man das simulieren könnte...

Das ist die Therorie. Selbst so einfache Dinge wie z.B. eine DLL von einem Ort laden, kann sich in der Sandbox anders verhalten.
In der Praxis und bei der Entwicklung der Anwendung ist es von Vorteil die Sandbox nachstellen zu können. Was wohl nicht geht.

[Bernhard Geyer]

Zitat:

Zitat von Bambini (Beitrag 1334411)

Die wenigsten Anwendungen sind für Windows 10 alleine, die universial App werden auch niemals auf Windows Phone laufen können.
Ich sehe da keinerlei Mehrwert für die Anwendung.

Also wenn diese "Konvertierten" Apps trotzdem nur unter dem normalen Windows laufen ist der Mehrwert nahe Null (außer auf irgendwelchen Marketingmappen den Haken bei "UnsersalApp" setzen zu können.
Ich sehe hier eher das man damit wieder zig neue Fehlerquellen sich einhandelt das dieser Container doch nur zu 99,9% sich transparent verhält.

[bra]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1334430)

Also wenn diese "Konvertierten" Apps trotzdem nur unter dem normalen Windows laufen ist der Mehrwert nahe Null (außer auf irgendwelchen Marketingmappen den Haken bei "UnsersalApp" setzen zu können.
Ich sehe hier eher das man damit wieder zig neue Fehlerquellen sich einhandelt das dieser Container doch nur zu 99,9% sich transparent verhält.

Der Mehrwert ist, dass die Kunden die App über den Appstore installieren und ggf. updaten können. Wie das genau funktioniert, wird sich halt noch zeigen.

[Bambini]

Zitat:

Zitat von bra (Beitrag 1334432)

Der Mehrwert ist, dass die Kunden die App über den Appstore installieren und ggf. updaten können. Wie das genau funktioniert, wird sich halt noch zeigen.

Wenn das der Vorteil sein soll, warum muss man dann den Umweg über universal App gehen. Warum nicht normale Setups?
Wenn man mal einen Blick in den App store für Mac OSX wirft und schaut wie viele z.B. Adobe Grafik Programme dort gelistet sind: genau 1 "Adobe Photoshop Elements 14", stellt sich Frage, warum?

Oder anders gefragt, warum sollte eine Software Firma 30% oder mehr an den Store Betreiber abtreten, wenn man sich das auch sparen kann;-)

[Bernhard Geyer]

Zitat:

Zitat von Bambini (Beitrag 1334437)

Zitat:

Zitat von bra (Beitrag 1334432)

Der Mehrwert ist, dass die Kunden die App über den Appstore installieren und ggf. updaten können. Wie das genau funktioniert, wird sich halt noch zeigen.

Wenn das der Vorteil sein soll, warum muss man dann den Umweg über universal App gehen. Warum nicht normale Setups?
Wenn man mal einen Blick in den App store für Mac OSX wirft und schaut wie viele z.B. Adobe Grafik Programme dort gelistet sind: genau 1 "Adobe Photoshop Elements 14", stellt sich Frage, warum?

Oder anders gefragt, warum sollte eine Software Firma 30% oder mehr an den Store Betreiber abtreten, wenn man sich das auch sparen kann;-)

:thumb: Wenn man natürlich problemlos diese 30% mehr verlangen kann/darf: "Hey, zahl doch 100€ damit du aus dem Store installieren darfst"

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1334438)

:thumb: Wenn man natürlich problemlos diese 30% mehr verlangen kann/darf: "Hey, zahl doch 100€ damit du aus dem Store installieren darfst"

Genau! "Na komm schon! Dein Update auf Windows 10 hast du doch dafür schon umsonst bekommen."

[stahli]

Hier erklärt A.Krämer, dass die Win10 Universal Apps unterschiedliche Anwendungen quasi kapseln können (u.a. auch Win32) und der Store daraus für die jeweiligen Plattformen lauffähige Pakete schnürt.

Ein Pro-Argument von ihm war, dass der Store das Projekt automatisch neu "kompilieren" kann, wenn es Plattformupdates gibt.
Das Projekt muss dann halt die Voraussetzungen für die gewählten Zielplattformen erfüllen.

(So habe ich das in Erinnerung.)

Falls jemand Interesse und Zugang zum Tutorial hat, vielleicht klärt das etwas auf.


EDIT: Kann natürlich sein, dass es da bei der Win32-Integration nur um NoneGUI-Code ging. Das weiß ich nicht mehr.
EDIT2: Die Seite zeigt das, was ich meinte: http://www.computerwoche.de/a/window...atform,3222064

[mquadrat]

Zitat:

Zitat von Bambini (Beitrag 1334437)

Zitat:

Zitat von bra (Beitrag 1334432)

Der Mehrwert ist, dass die Kunden die App über den Appstore installieren und ggf. updaten können. Wie das genau funktioniert, wird sich halt noch zeigen.

Wenn das der Vorteil sein soll, warum muss man dann den Umweg über universal App gehen. Warum nicht normale Setups?

Automatisches Neu-Installieren, Automatischer Rollback bei fehlerhafter neuer Version (Self-Healing), Background-Install, einheitlicher Prozess, .....

Was ich amüsant finde ist, dass immer alle nach einer Windows-Paketverwaltung geschrien haben. Und jetzt wo sie da ist (nichts anderes ist der Store ja), isses auch wieder nicht recht :)

[Uwe Raabe]

Zitat:

Zitat von mquadrat (Beitrag 1334561)

Was ich amüsant finde ist, dass immer alle nach einer Windows-Paketverwaltung geschrien haben. Und jetzt wo sie da ist (nichts anderes ist der Store ja), isses auch wieder nicht recht :)

Frei nach Uli Stein:

[Bernhard Geyer]

Zitat:

Zitat von mquadrat (Beitrag 1334561)

Zitat:

Zitat von Bambini (Beitrag 1334437)

Zitat:

Zitat von bra (Beitrag 1334432)

Der Mehrwert ist, dass die Kunden die App über den Appstore installieren und ggf. updaten können. Wie das genau funktioniert, wird sich halt noch zeigen.

Wenn das der Vorteil sein soll, warum muss man dann den Umweg über universal App gehen. Warum nicht normale Setups?

Automatisches Neu-Installieren, Automatischer Rollback bei fehlerhafter neuer Version (Self-Healing), Background-Install, einheitlicher Prozess, .....

Was ich amüsant finde ist, dass immer alle nach einer Windows-Paketverwaltung geschrien haben. Und jetzt wo sie da ist (nichts anderes ist der Store ja), isses auch wieder nicht recht :)

Nicht zu vergessen den Wegezoll den MS bei Bereitstellung über den Store verlangt.
Ich bleibe lieber bei unserer XCopy-Installation.