Hier eine aktuelle News zum Thema ARM, da es langsam wirklich relevant zu werden scheint:

https://www.heise.de/news/Microsoft-stellt-ARM-Surfaces-im-Mai-vor-9681859.html

Habe gerade diese Liste mit nativer Software entdeckt, die auf ARM Systemen nicht emuliert werden muss und daher effizienter läuft. Mein Projekt ist dort auch aufgelistet, freu:)

https://armrepo.ver.lt/

Mal schauen wie es weitergeht

So, seit ein paar Monaten bin ich umgestiegen auf ein älteres Macbook, jedoch schon mit M1 CPU, und bin total zufrieden. Windows 11 on ARM läuft wunderbar in Parallels (nach ein paar wenigen Feinjustierungen). Der Lüfter geht so gut wie nie an, das Gehäuse wird nicht heiß. So macht es Spaß, mit VIsual Studio zu arbeiten. Für meine Entwicklungsumgebung habe ich x86 nun beerdigt.

Kleine Ergänzung: Möchte man überprüfen, ob es sich bei einem MSI-Paket auch wirklich um natives Arm64 handelt, kann man das Kommandozeilentool "MsiInfo.exe" verwenden. Das Tool ist Teil der Windows SDK.

Beispielaufruf in PowerShell:

& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x86\MsiInfo.exe" mysetup.msi

Es werden mehrere Eigenschaften in der Konsole ausgegeben. Relevant ist der Wert für Template(MSI CPU) aus der Eigenschaft mit der Nummer 7, z.B.

...
[ 7][/p] Template(MSI CPU,LangIDs) = Arm64;1033
...

Wer seine Installationspakete bereits mit WiX v3 erstellt kann mit relativ wenig Aufwand auch native Arm64 MSI-Pakete erstellen.

Voraussetzung ist ein bestehendes WiX-Setup Projekt in Visual Studio (ich verwende VS 2022) mit installierter WiX v3 Extension und installierten Build Tools.

Da es für die aktuelle Version 3.14 noch kein offizielles Release gibt, muss der Developer Build (v3.14.0.6526 oder höher) installiert werden. Dazu Visual Studio beenden, das WiX Toolset herunterladen und installieren.

In der Setup-Prokjektdatei "<Projekt>.wixproj" die Plattform-Konfiguration innerhalb "<Projects>" hinzufügen

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|ARM64' ">
  <DefineConstants>Debug</DefineConstants>
  <OutputPath>bin\$(Platform)\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Platform)\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|ARM64' ">
  <OutputPath>bin\$(Platform)\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Platform)\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>

In der ".wxs" Datei ist es nötig, den Wert für "InstallerVersion" abzuändern in 500 (vorher: 200). Für das Installationsverzeichnis kann analog zu x64 die Variable "ProgramFiles64Folder" verwendet werden.

Damit sollte der Buiild eines Arm64 MSI-Pakets möglich sein.

Danke für die Infos! Der Quellcode speziell bei den UI Abhängigkeiten (z.B. Magic - The User Interface Library for .NET - Article) ist schon uralt. Sorry, das hatte ich vergessen zu erwähnen. Ist ja dann klar dass meine Erfahrungen hier für die wenigsten relevant sein dürften.

Ich habe mein (WinForms-) Projekt nun teilweise unter .NET 7 zum Laufen gebracht. Das sind meine Erfahrungen soweit:

• Die Klasse "ContextMenu" ist nicht mehr verfügbar
• Referenz auf System.Web ist nicht mehr erlaubt
• Fast alle UI-Elemente sehen etwas anders aus (Größe, Position) bzw. werden in einem Fall (PropertyGrid) viel zu klein dargestellt
• Es gibt ein Problem bei der Verwendung der Klasse "MemoryMappedFiles", das ich mir noch näher anschauen muss
• Die Performancesteigerung (Programmstart und zur Laufzeit) bei Arm64 in meinem Fall ca. 10%

Die Performance hat mich etwas enttäuscht, da hatte ich mir mehr erhofft. Hoffentlich bringt die AOT Kompilierung noch was. So wie ich das verstanden habe werden aktuell jedoch nur Konsolenanwendungen unterstützt.

Weiterhin ist mir aufgefallen, dass der Build mit Target .NET Framework 4.8.1 unter x86 auch auf Windows Systemen läuft, die z.B. nur das .NET Framework 4.0 installiert haben. Das liegt wohl daran, dass ich keine Funktionen verwende, die es nur in höheren Versionen des .NET Frameworks gibt.

Ich denke nun, dass für eine deutliche Performance-Steigerung ein umfassendes Code Refactoring nötig ist.

Das hört sich alles sehr interessant an. Laut dem Tool "upgrade-assistant" müssen vor der Migration nach .Net 7 noch Anpassungen vorgenommen werden. Sieht aber alles machbar aus. Das werde ich mir für mein Freizeitprojekt auf jeden Fall mal anschauen.

Auch ein Vergleich von emulierter und nativer Software ist kaum sinnvoll.
Gerade da ARM einige Hardware Befehle per Software emulieren muss, kann hier ein deutlicher Performance Unterschied bemerkbar sein.
Dies liegt schon in der Natur der Sache.

Ja, das ist mir klar. Mir hat der Vergleich mit der emulierten Exe deutlich gezeigt, dass es Sinn macht, Software auch als Arm build anzubieten. Es hätte ja auch sein können, dass der Performance-Unterschied so gering ist, dass man keinen Unterschied merkt.

...und dass deine Aussage, dass Arm quasi im Alleingang die Welt rettet, vollkommener Humbug ist.

Was bist du denn für ein Spaßvogel? So einen Schwachsinn habe ich niemals behauptet

Are Arm processors more efficient than x86 processors?

ChatGPT:
Arm processors are generally more power-efficient than x86 processors, but whether they are more efficient overall depends on the specific use case.

Arm processors are designed to be more power-efficient than x86 processors, which are used in most desktop and laptop computers. Arm processors are commonly used in smartphones, tablets, and other mobile devices where power efficiency is important.

One reason Arm processors are more power-efficient is that they use a different instruction set architecture (ISA) than x86 processors. Arm processors use a Reduced Instruction Set Computing (RISC) architecture, which requires fewer instructions to perform a given task compared to the Complex Instruction Set Computing (CISC) architecture used by x86 processors. This reduces the amount of power needed to execute instructions.

Another reason Arm processors are more power-efficient is that they are typically designed for lower clock speeds and use less power as a result. This means that they consume less power overall compared to x86 processors, which are designed to run at higher clock speeds and consume more power.

However, x86 processors are generally better at handling complex workloads, such as those found in desktop and server applications. They also have a larger software ecosystem, with many applications and tools designed specifically for x86 architecture.

In summary, Arm processors are more power-efficient than x86 processors and are commonly used in mobile and embedded devices. However, x86 processors are generally better at handling complex workloads and have a larger software ecosystem. The choice of processor architecture depends on the specific use case and performance requirements.

Mit Visual Studio 2022 lassen sich auch auf einem x86 Rechner native Arm64 builds erstellen, sofern man das Projekt auf .Net Framework 4.8.1 migriert. Das habe ich nun ausprobiert und es hat problemlos funktioniert. Ich musste natürlich auch die verwendeten DLLs auf die neue .Net Version migrieren und als Arm64 bauen. Das war aber kein Problem da ich den Quellcode habe. Auf meinem Galaxy Book Go läuft der native Build deutlich performanter als der emulierte x86 build. Mit .Net Core würde es vermutlich performanter laufen. Ich weiß nicht wie hoch der Migrationsaufwand ist. Werde ich mir mal anschauen.

Auf dem Arm Windows erkennt man eine native Exe daran, dass der Button "Change emulation settings" (Rechte Maustaste auf exe-Datei->Reiter "Compatibility") ausgegraut ist. Auch eine Arm32 Exe muss auf einem Arm64 Windows emuliert werden.

Jetzt noch native msi-Pakete erstellen. Das soll mit Wix 3.14 (Dev Version) möglich sein.

Ich bin schon gespannt auf Laptops mit dem neuen Prozessor Snapdragon 8cx Gen4. Da könnte ein Nachfolger für mein altes T480s dabei sein..

Hi,

dass Microsoft auch für das .NET Framework den nativen Support für Arm64 anbietet könnte der Beginn einer neuen Ära sein. Ich hoffe, dass demnächst (zumindest auf dem Laptop-Markt) alle x86-Systeme ersetzt werden (so wie es aktuell Apple macht mit "Apple Silicon"), unserer Umwelt zuliebe. Wichtig ist dabei, dass möglichst viel Software auch für Arm gebaut wird, damit sie nicht emuliert werden muss - was natürlich Performance-Einbußen mit sich ziehen würde.

Meine aktuelle Software (noch auf .NET Framework 4.0) werde ich auf die aktuelle Version 4.8.1 migrieren, damit ich auch native Arm-Builds anbieten kann. Ich habe mir dazu gerade ein gebrauchtes Samsung Galaxy Book Go mit Snapdragon CPU und Windows 11 für 200€ gekauft (in Zukunft wird es dann vermutlich ein MacBook mit Windows 11 Arm und Parallels).

Da mein altes Zertifikat nur 1 Jahr gültig ist und im April abläuft, habe ich mir nun ein neues Zertifikat bestellt, und zwar wieder bei K-Software. Einen Monat vor Ablauf des Zertifikats schickt K-Software eine Hinweismail raus. In dieser Mail war bei mir auch ein Gutschein-Code.

Aufgrund der guten Erfahrungen habe ich mir ein Zertifikat für 4 Jahre bestellt (wieder als Privatperson). Gekostet hat mich das Zertifikat $236 (Normalpreis ohne Gutschein $268). Ich habe mit Paypal bezahlt. Es wurden 196,30€ abgebucht.

Das Zertifikat habe ich innerhalb von 2 Tagen erhalten. Es war lediglich nötig, die telefonische Verifizierung durchzuführen. Ich habe nach der Bestellung Comodo meine alte Ordernummer per Mail geschickt.

Aufgrund folgender Änderung bei Comodo werde ich vermutlich in 2 Jahren die F2F Verfikation erneut durchführen müssen.

Neben Abstürzen und Stromausfällen ist mir noch ein weiteres Szenario eingefallen. Da es sich um eine portable App handelt kann die App z.B. auf einem USB-Stick ausgeführt werden. Zieht der Nutzer beim Beenden der App den Stick vorzeitig heraus, haben wir dasselbe Problem.

Ich habe nun die Speicherlogik in etwa wie oben beschrieben implementiert. "Getestet" habe ich es mit einem alten, schön langsamen USB-Stick (128 MByte), den ich mehrfach beim Schreiben gezogen habe. In jedem Test war eine der beiden Dateien noch in Ordnung. Die Sache hat sich für mich damit erledigt.

@all
Vielen Dank für die Antworten!

@Abt @inflames2k
Dies ist jetzt das erste Mal seit 2 Jahren, dass mir das passiert ist - also so gut wie nie. Trotzdem ist es für mich einmal zu viel. Ich kann das jetzt nicht einfach verdrängen...

@LaTino
Eigentlich sollte es doch die Aufgabe des Dateisystems sein, dafür zu sorgen, dass keine korrupten Daten entstehen können. Aber NTFS unterstützt leider keine Transaktionen. Oder doch?

@chilic
Ja, so sehe ich das auch.

@Sir Rufo
Die neue Grafikkarte liegt schon in der Packstation 😁 Ich hoffe damit läuft mein System wieder stabil.

Hallo,

in meiner .NET 4.0 WinForms App habe ich mir die Konfigurationsdatei zerschossen, als beim Schließen der App mein System zufällig abgestürzt ist (ich vermute meine Grafikkarte verabschiedet sich langsam).

Beim erneuten Starten der App konnte dann die Konfigurationsdatei nicht mehr eingelesen werden. Ich habe mir die XML-Datei daraufhin in einem Texteditor angeschaut und dann gemerkt, dass die Datei korrupt ist, da sie nur haufenweise "NUL" Einträge enthielt. D.h., sämtliche Konfigurationsdaten sind verloren gegangen.

Um den kompletten Datenverlust bei einem Absturz in Zukunft zu vermeiden, würde ich meinen SettingsProvider folgendermaßen umschreiben:*Beim Beenden der App überprüfen, ob sich etwas an der Konfiguration geändert hat. Falls nein, wird die Konfigurationsdatei nicht neu geschrieben. *Falls sich die Konfiguration geändert hat, soll die Konfiguration zunächst in eine temporäre Datei geschrieben werden, die danach über die Ziel-Datei kopiert wird. (Sollte das System während des Kopiervorgangs abstürzen, so hat man die Daten immerhin noch in der temporären Datei.) Zuletzt wird die temporäre Datei gelöscht.

Was haltet ihr davon? (Datenbanken wie SQLite kommen nicht in Frage, da man die Dateien in einem Texteditor leicht abändern können soll)

Jetzt muss jeder entscheiden, ob 185€ einem einen halben Tag Rennerei wert sind, sprich ob Arbeiten+185€ zahlen nicht günstiger ist als nen halben Tag Urlaub.

In meinem Beitrag oben habe ich noch vergessen zu erwähnen, dass ich bei der Anwaltsuche parallel auch eine Anwältin im Internet gefunden hatte, die die Verifikation per Skype durchführt. Hatte mich dann aber trotzdem für den lokalen Anwalt entschieden. Bei der Verlängerung werde ich die Verifikation über diese Anwältin per Skype durchführen.

Da wärste aber mit DigiCert quasi günstiger weggekommen.
Kostet zwar 225$ (~200€) aber dafür alles via Skype in 15 Minuten erledigt.

Bei DigiCert muss ich beim Verlängern des Zertifikats in einem Jahr aber auch wieder 200€ ausgeben.

Wenn ich bei Comodo zum Verlängern nicht mehr zum Anwalt muss, zahle ich nur 80€ für jedes weitere Jahr.

Ich bin in etwa so vorgegangen:* Anwaltsuche bei mir lokal, wichtig dabei ist ein Eintrag in folgendem Register: Bundesrechtsanwaltskammer

• Das PDF für die F2F Verfikation per Mail an den Anwalt geschickt mit der Frage, ob er dies leisten kann
• Termin ausgemacht und Perso, aktuelle Telefonrechnung, aktuelle Stromrechnung, Kreditkarte und das ausgedruckte PDF von Comodo für den Termin vorbereitet
• Beim Termin wurde das Forumlar von Comodo ausgefüllt und unterschrieben, dieses wurde dann zusammen mit den mitgebrachten Dokumenten beglaubigt. Kosten waren leider hoch, insg. 110 €
• Die Beglaubigung in 300dpi in Farbe eingescannt (so dass man auch schön das Siegel erkennt), in ein PDF-Dokument gepackt, auf meine eigene Domain hochgeladen und den Link per Mail an Comodo geschickt
• Anschließend wurde ich im letzten Schritt auf meinem Festnetz-Telefon angerufen. Den Anruf habe ich selbst über ein Webinterface von Comodo durch Klick auf einen Button initiert, und ein paar Sekunden später klingelte das Telefon. Ein Automat gab mir einen Zahlencode durch, den ich dann ins Webinterface eingeben musste.
• Danach habe ich das Zertifikat erhalten. Da aber noch Straße und Hausnummer meiner Adresse enthalten war, was ich nicht wollte, habe ich über K Software ein Re-issue des Zertifikats (kostenlos) ohne diese Angaben gemacht, was innerhalb von einem Arbeitstag erledigt war.

Ich habe den Eindruck, dass Comodo den Mail-Verkehr selbst als Teil des Prüfungsprozess nutzt. In meinem Gesendet-Ordner sehe ich insgesamt 7 Mails, die ich als Antwort auf Anfragen an Comodo versendet habe. Es wurden z.B. auch banale Sachen gefragt, z.B. was sie im o.g. Anwaltsregister eingeben müssten um meinen Anwalt zu verifizieren. Ich habe aber auf alle Anfragen stets höflich geantwortet.

Für den Mailverkehr habe ich die Mail-Adresse info@<meine-domain> verwendet. Die gesamte Kommunikation mit Comodo erfolgte auf englisch. Die Kosten betrugen insgesamt ca. 190€, plus den halben Arbeitstag für den Termin beim Anwalt.

EDIT: Im Internet findet man auch Anwälte, die die F2F Verifikation per Skype durchführen.

Wollte nur kurz rückmelden, dass ich nach einem doch recht aufwendigen Prozess heute endlich mein Code Signing Zertifikat erhalten habe 🙂

Falls jemand Interesse an Details zum Prozess für Privatpersonen hat, bitte hier Bescheid geben - dann fasse ich den Ablauf kurz zusammen.

So einen Zampano hatte ich nicht am Hals. Eine DUNS-Nummer und die Gewerbeanmeldung waren ausreichend.

Ok, als Privatperson kann ich das nicht vorweisen. Wahrscheinlich ist deshalb die Face-To-Face Verifikation nötig.

Durch das Feedback hier hab ich gestern bei DigiCert ein Zertifikat bestellt.

Bei DigiCert kostet ein Code Signing Zertifikat für 1 Jahr aktuell 223$. Da bezahle ich lieber einmalig (hoffentlich) für den Notar und kann anschließend für 80€ pro Jahr verlängern...

Hm, Comodo verlangt nun von mir, dass ich zum Notar gehe:

In order to validate your Individual code signing certificate, we request you to provide us the Face to face verification document. Could you please download it from the below link and follow the instruction on the same and send to us.

>

Da werden also zusätzlich zu den 80,95€ für das Zertifikat noch Notarkosten fällig 🙁

Ich hoffe mal dass mir der Besuch beim Notar für die Zertifikatsverlängerung in einem Jahr erspart bleibt...

Danke an alle für die Antworten.

Ich habe eben ein Code Signing Zertifikat für 1 Jahr bei K Software bestellt.

Ich hab meine Zertifikate von StartSSL; ist so mit der bekannteste.

Danke für deine Antwort. StartSSL hatte ich auch schon entdeckt - doch dann habe ich diesen Artikel gefunden: Code Signing - Eine Anleitung.

In den Kommentaren behauptet jemand, dass die Signatur von StartSSL Zertifikaten ungültig wird, sobald die Lebensdauer des Zertifikats erreicht wird. Der Verfasser des Artikels bestätigt dies dann auch.

Das würde bedeuten, dass nach Ablauf der Lebensdauer für alle signierten Binaries wieder die Warnung "Unbekannter Herausgeber" erscheint. Kannst du dies bestätigen?

Hallo,

für mein privates Softwareprojekt möchte ich gerne die .exe mit einem Code Signing Certificate signieren, damit die Warnung "Unbekannter Herausgeber" nicht mehr erscheint. Wichtig wäre mir, dass das Zertifikat von Windows 7 und höher anerkannt wird. Außerdem möchte ich nicht, dass Straße und Hausnummer meiner Adresse im Zertifikat enthalten sind. Das ganze sollte auch nicht mehr wie 100€ kosten.

Auf der Suche nach einem passenden Anbieter bin ich auf K Software gestoßen, was hier in älteren Posts auch schon empfohlen wurde. Ist dieser auch heute noch zu empfehlen? Oder gibt es bessere Alternativen?

Ich habe mich nun umentschieden und meine Software von den o.g. Portalen entfernen lassen. Demnach rate ich dem TE nun auch davon ab, solche Download-Portale zur Veröffentlichung der eigenen Software zu verwenden. Das von Abt erwähnte Chocolatey ist imho eine gute Alternative zu Download-Portalen. Funktioniert auch unter Windows 7 😁 👍

Folgende Seiten, die hier noch nicht genannt wurden, möchte ich dem TE empfehlen:

alternativeTo: Hier kann man die eigene Software als Alternative zu ähnlicher Software hinzufügen.

Slant: Hier kann man zu Fragen wie z.B. "What is the best Markdown editor for Windows?" seine eigene Software als "Produkt" hinzufügen.

Wikipedia: Hier kann man seine Software in entsprechenden Listen hinzufügen, z.B. im Falle eines Text Editors -> Comparison of text editors

@LaTino
Was würdest du denn dem TE empfehlen?

P.S. In meiner Firma werden die von mir genannten Portale nicht geblockt. Und es ist keine kleine Firma.

Software, die auf solchen Portalen liegt, ist für mich pauschal unseriös. Denke nicht, dass ich damit alleine im Wald steh.

Das hieße aber auch, dass z.B. Browser wie Firefox oder Google Chrome unseriös sind, da diese z.B. bei Softpedia zum Download angeboten werden. Ich glaube nicht, dass es viele gibt die diese Software als unseriös einstufen.

@P.St. Ist der Winows Store keine Option für dich?

Als ich damals das erste Mal vom Windows Store gehört habe, hatte mich schon eine kleine Euphorie gepackt. Ich dachte, genau das ist es was ich suche. Die Euphorie war leider schnell vorbei, als ich erfuhr, dass der Store nicht für Windows 7 angeboten wird. Für mich ein Muss-Kriterium, da ich meine Software größtenteils selbst auf der Arbeit verwende, wo halt nur Windows 7 läuft. Trotzdem danke für den Hinweis.

Danke für die Antworten. In der Tat scheinen bei so gut wie allen Download-Portalen zumindest die Top-Downloads mit Crapware verseucht zu sein, was natürlich für den Nutzer sehr schlecht ist. Hier gibt es z.B. einen Artikel über dieses Thema Mind the PUP: Top download portals to avoid. Stellt sich die Frage, warum tun die das?

Ich stelle mir das so vor:
Ein Download-Portal pickt sich Software mit hohen Downloadzahlen raus und fragt die Anbieter, ob sie die Software in ihren eigenen Installer (mit Crapware) packen dürfen. Als Gegenleistung bekommt der Softwareanbieter einen Teil der Einnahmen die dadurch entstehen. Er kann nun zusagen und sich denken "Cool, ich bekomme Geld und ausserdem gibt es auf unserer Webseite ja noch den normalen Download" oder aber auch ablehnen und damit verhindern, dass seine Software mit Crapware ausgeliefert wird.

Demnach wäre hier nicht alleine das Download-Portal dafür verantwortlich, dass Crapware auf diesem Weg verbreitet wird.

Ich denke, dass ein großer Teil der angebotenen Software frei von Crapware ist. Bei meiner Software (mit relativ wenigen Downloads) ist das definitiv so (kann man ja leicht über die Prüfsumme feststellen). Ausserdem bin ich froh, dass es diese Download-Portale gibt, ansonsten würde niemand meine Software kennen. Speziell bei Softpedia hat man sich richtig mit meinem Programm auseinandergesetzt und eine Beschreibung verfasst, die um Längen besser ist als meine eigene - das ganze natürlich kostenlos.

@pinki @LaTino
Ich habe auf verschiedene Seiten der o.g. Download-Portale geklickt, jedoch hat mein Virenscanner (McAfee AntiVirus/AntiSpyware Enterprise Edition) keine einzige Warnung abgegeben. Habt ihr hier vielleicht einen konkreten Link, wo euer Virenscanner anschlägt?

@p!lle @mfe @pinki

Da würde ich jetzt aber gerne mal eine Begründung dazu hören, warum diese Portale "dubios" sein sollen bzw. warum man nicht auf "solche Quellen zurückgreifen" sollte. Habt ihr schon schlechte Erfahrungen gemacht?

Ergänzung zum letzten Post:

~~Zum Veröffentlichen meiner (englischsprachigen) Software (Freeware) nutze ich aktuell die Portale CNET Download, Freeware Files, Softpedia und FileForum (Betanews).~~Damit die Software auch akzeptiert wird, brauchst du aber imho eine eigene Webseite oder einen Blog (ich habe im Moment nur einen Blog bei blogspot), wo du die Releases veröffentlichst. Außerdem wird ein direkter Download-Link erwartet - wie schon erwähnt bietet sich hier Google Drive an. Wichtig ist, dass man die Datei zu jeder Zeit mit einem Klick herunterladen kann.

EDIT: Links angepasst
EDIT2: Ich nutze diese Portale nun nicht mehr (siehe mein Beitrag vom 10.01.2017 19:25)

Ich nutze dafür Google Drive. Seit ca einem Jahr biete ich darüber Downloads an und hatte noch keine Probleme