ProgrammierenSoftwareWindowsMartin Richter - Mo 11 Aug 2014 21:13

Man lernt nie, aus. In dem Fall betrifft es ein wenig die Batch-Programmierung mit CMD.EXE.

Für einen Batch, der einen Teil eine Datensicherung eines Hyper-V Servers machen sollte benötigte ich ein Verzeichnis mit dem Tagesdatum, aber im Format YYYY-MM-DD. %date war mir bekannt und auf unseren Rechner liefert das aber, DD.MM.YYYY.

Ein wenig Suche im Netz brachte mich zu Substring-Funktionen bei der Variablenersetzung, die ich noch gar nicht kannte. Hängt man hinter eine Variable Doppelpunkt und Tilde kann man Startposition und Länge eines Substrings angeben.

Entsprechend ist der Batch also ganz schnell geschrieben 😉 :

SETLOCAL
SET TargetDir=D:\BackupHyperV %date:~6,4%.%date:~3,2%.%date:~0,2%
MD "%TargetDir%"
HardwareInstallationSoftwareWindows 7Windows 8Martin Richter - Do 27 Jun 2013 18:06

Ich hatte immer wieder Probleme, dass mein Papierkorb leer war, obwohl ich gerade eine Datei dort hin verschoben war.

Es schien auch alles andere zu funktionieren, denn ich konnte auch Aktionen im Explorer rückgängig machen und Dateien wieder so aus dem Papierkorb herausholen. Nur anzeigen konnte ich den Inhalt des Papierkorbes nicht mehr.

Analyse der Festplatte ergab, aber, dass die Dateien vorhanden sind, CHKDSK keinen Fehler liefert… nichts problematisches eigentlich zu finden. Ich habe keine Ahnung wie oft ich den entsprechenden Ordner entfernt habe und hoffte, dass sich die Datenbank des Papierkorbes irgendwann fängt. Aber dem war nicht so 🙁
Ich löschte eine Datei, die kurz im Papierkorb erschein um sofort wieder zu verschwinden.

Irgendwann hat es mich so genervt, dass ich doch weiter auf die Suche gegangen bin und habe in einem Forum einen Hinweis für eine Richtung gefunden, die ich gar nicht auf der Rechnung hatte.
Die Ursache war ein Wibu Codemeter-Dongle. Dieser Dongle steckt immer in meiner Entwicklungsmaschine um bestimmte Szenarien testen zu können. Wir benutzen für größere Lizenzen die Wibu-Codemeter-Dongles seit einigen Jahren mit gutem Erfolg und wir sind auch sehr zufrieden mit der Qualität, sowohl von Hardware als auch Software und SDK.

Der eingesteckte Codemeter Dongle meldete sich als  lokaler Datenträger an. Dadurch wollte Windows auch scheinbar den Papierkorb auf diesem Laufwerk suchen und finden. Aber eigentlich ist das Ding nur eine RAM-Disk, die keinen permanenten Speicher bietet. Sobald der Dongle als lokale Festplatte angemeldet ist, funktioniert auch der Windows-Papierkorb nicht mehr.
Ein schneller Test zeigte, dass der Papierkorb nur bei nicht eingestecktem Dongle verfügbar war.
Weitere Recherche ergab, dass die eigentliche Ursache ein Bug in Windows 7/2008R2 ist. Netterweise ist sogar ein Hotfix für Windows-7 und Windows Server 2008R2 verfügbar (Links siehe unten), aber leider hat der seinen Weg nach Windows-Update nicht gefunden :(.

Aber es lässt sich auch ohne Installation des Hotfixes schnell mit der Codemeter Runtime schnell ändern.
Die Codemeter Runtime gibt folgende Auskunft zu dem Dongle.

C:\...\CodeMeter\Runtime\bin>cmu32  -s1-2345678 --show-config-disk
cmu32 - CodeMeter Universal Support Tool.
Version 5.00b of 2013-May-14 (Build 1067) for Win32
Copyright (C) 2007-2013 by WIBU-SYSTEMS AG. All rights reserved.

- CmStick with Serial Number 1-2345678 and version 1.16
  Version:            1.16
  Flash Size:         no real flash available
  Virtual Drive:      D:
  Configuration:      LocalDisk with ActivePartition
  File System:        FAT32
  Boot-Code:          Int18 Boot Code
  Mdfa:               0x539

Über die entsprechenden Commandline Utilities der Wibu-Runtime kann man das aber umkonfigurieren. der Befehl lautet:
cmu32 -s1-2345678 –set-config-disk RemovableDisk
Dazu muss mit dem Parameter -s die Seriennummer des betroffenen Dongles angegeben werden.

C:\...\CodeMeter\Runtime\bin>cmu32 -s1-2345678 --set-config-disk RemovableDisk
cmu32 - CodeMeter Universal Support Tool.
Version 5.00b of 2013-May-14 (Build 1067) for Win32
Copyright (C) 2007-2013 by WIBU-SYSTEMS AG. All rights reserved.

  Communication mode changed successfully.

  Please replug your CmDongle to apply the changes.

Also Dongle wie angezeigt einmal rausziehen und wieder anstecken.
Und sie da 🙂 mein Papierkorb ist sofort wieder da und sichtbar. „Gelöschte Dateien“ erscheinen wir gewohnt.
Die Kontrolle zeigt nun einen Removeable-Device, wie das bei anderen USB-Sticks auch der Fall wäre.

C:\...\CodeMeter\Runtime\bin>cmu32  -s1-2345678 --show-config-disk
cmu32 - CodeMeter Universal Support Tool.
Version 5.00b of 2013-May-14 (Build 1067) for Win32
Copyright (C) 2007-2013 by WIBU-SYSTEMS AG. All rights reserved.

- CmStick with Serial Number 1-2345678 and version 1.16
  Version:            1.16
  Flash Size:         no real flash available
  Virtual Drive:      D:
  Configuration:      RemovableDisk with ActivePartition
  File System:        FAT32
  Boot-Code:          Int18 Boot Code
  Mdfa:               0x539

Weitere Hinweise zu dem Vorgehen finden sich auf den Microsoft und Wibu-Supportseiten hier:
http://support.microsoft.com/kb/2677246/en-us
http://www.wibu.com/de/faq-codemeter/question/single/warum-ist-mein-papierkorb-leer-wenn-ein-cmstick-angesteckt-ist-138.html
http://www.wibu.com/de/faq-codemeter/question/single/wie-kann-man-einen-cmstick-ohne-speicher-umkonfigurieren-145.html

C++ProgrammierenWindows APIMartin Richter - Fr 16 Nov 2012 16:21

Ja! Das könnte man denken. Strg+V sowie Umschalt+Einfg sind Shortcuts um etwas aus der Zwischenablage einzufügen.
Man könnte weiterhin davon ausgehen, dass Windows in einem Edit-Control beide gleich behandelt. D.h. benutzt der Anwender Strg+V oder Umschalt+Einfg oder das  im Edit-Control, dann wird immer der selbe Vorgang ausgelöst.

Schön wäre es ja 🙁 …

Sowohl bei Strg+V, wie auch bei Umschalt+Einfg und über das Kontextmenü wird WM_PASTE an das Edit-Control gesendet. Schön!

Aber hat das Edit-Control den Stil ES_READONLY – ist also als nur lesend definiert -, dann wird bei Eingabe von Strg+V die Nachricht WM_PASTE nicht gesendet. Auch das Kontextmenü blendet den Menüpunkt Einfügen brav aus. Auch das ist gut so und wie erwartet.

Aber was passiert bei Umschalt+Einfg?
Ja. Das unerwartete passiert und in diesem Fall wird doch WM_PASTE gesendet…

Herausgekommen ist das als Bug in unserer Software bei einer speziellen Edit-Control Klasse, die auch bestimmte andere Datenformate aus der Zwischenablage verstehen soll. Ein Kunde stellte letzten Endes fest, dass er über Umschalt+Einfg weiterhin auch in ein Readonly-Control Daten einfügen kann.

Ich war ziemlich überrascht als ich dieses „unlogische“ Verhalten im Testfeld nachvollziehen konnte.
Wer hätte es gedacht? Ich nicht…

ATLC++MFCProgrammierenVS 2012Windows APIMartin Richter - Fr 04 Mai 2012 09:15

Gestern Abend hatten wir hier auf der ADC 2012 für C++ in Ohlstadt bei einem schönen Abendevent eine Q&A. Letztes Jahr fand diese Q&A auf einer Schiffahrt auf dem Chiemsee statt. Dieses Jahr war es ein Fußweg von ca. 20 Minuten vom Konferenzhotel, zu einem großen „Grillplatz“, dort standen Zelte, Fackeln Lagerfeuer und es wurde gut gegessen und wie immer viel „Networking“ betrieben.

Wie auch letztes Jahr sollten detailierte Fragen auf diese Q&A zu späterer Stunde vertagt werden.

DIE FRAGE die viele Entwicklern brennend interessierte war:
Kann man mit VS-11 Programme für Windows XP entwickeln oder nicht?

Rede und Antwort stand in diesem Fall Steve Teixeira, als Director of Program Management. Also in diesem Fall jemand, der wirklich etwas sagen und auch mit zu entscheiden hat.

Ich gebe seine Antwort von Steve, auf diese Frage zusammengefasst wie folgt wieder:

  1. Zu dem Zeitpunkt als die Entscheidung für das Fallenlassen vom XP-Support gefällt wurde erschien dies als richtig.
    Jetzt muss man allerdings eingestehen, dass diese Entscheidung ein Fehler von Microsoft war.
  2. Die Benutzerzahlen wurden weiter als sinkend berechnet. Man vermutete, dass zum Zeitpunkt der Veröffentlichung von VS-11 noch maximal 20% XP-Nutzer vorhanden wären. Neue Umfragen gehen aber von einer Verbreitung von mindestens noch 46% Windows XP Installationen aus.
  3. Bei Microsoft wurde auch vermutet, dass es genügt den Entwicklern die neue VS-11 Oberfläche anzubieten aber das für das Compilieren das Toolset von VS-2010 genügen würde. Es wurde unterschätzt wie groß das Interesse an den neuen Compiler Funktionen in VS-11 mit C++11  ist. Was eben auch AMP und neue STL Funktionalität einschließt.
  4. Die Folge ist nun, dass Microsoft die Entscheidung für das Fallenlassen des Windows-XP Support neu überdenkt.
    Allerdings kann dies nicht mehr bis zum RTM geschafft werden.
    (Anmerkung von mir: Aktuell in der Beta wurde der gesamte Code, der die Windows-Vista/7 Funktionen isoliert entfernt und alle DLLs werden implizit geladen).

Möglich ist also, dass es ein Featurepack geben wird, dass nach dem RTM ausgeliefert wird, und in dem es dann doch einen XP Support in allen Bibliotheken und im Compiler gibt.

Die Antwort erschien mir ehrlich und geradeaus und war gewisslich keine Vertröstung ohne echten Hintergrund.
Ich weiß nicht wie groß wirklich die Chancen sind, aber diese Aussage deckt sich auch mit den „Gerüchten“, die ich um 5 Ecken gehört habe, und deckt sich auch mit der internen Diskussion, die mit den MVPs geführt wird.

Meine persönliche Schätzung ist eine 25 prozentige Chance, dass wir doch noch einen Windows-XP Support im VS-11 erhalten werden.

Lassen wir und überraschen. Aber es ist eine gute Nachricht ❗

PS: Ich schreibe dies direkt von der ADC für C++ 2012 in Ohlstadt.

Nachträge und Kommentare habe ich direkt in den Blog-Post übernommen, da diese manchmal übersehen werden:

Kommentar 1 vom 04.05.2012 von Steive Teixeira zur Klarstellung:

Hi Martin,
It was great to see you at ADC C++ this week! Just so that there is no confusion for the readers of your blog, the issue of XP support for C++ in Dev11 is one we’re taking very seriously, and we’re continuing to take customer feedback on Dev11 beta. However, we are not yet prepared to make an announcement on platform support for the RTM version of Dev11. We will be making an announcement on this in the coming weeks.
Thanks!
Steve

Kommentar 2 vom 04.05.2012 von Michael Kühlshammer 

Steve Teixeira schickte mir heute einen Link für einen Workaround und empfahl mir, dass möglichst viele Leute auf dem unten angegebenen Link einen Beitrag dazu schreiben sollen (dafür voten sollen), dass der VC11-Compiler auch Code für Windows XP erzeugt. Hier die Email-Antwort von Steve Teixeira:

“Thanks for your email. We continue to devote resources to and support MFC in Dev11. The Windows XP issue is still unsettled, and I appreciate your feedback on this. You me have seen that I posted some of my thoughts on XP support in the comment thread of this blog entry on the VC++ team blog: http://blogs.msdn.com/b/vcblog/archive/2012/04/18/10295093.aspx.

Thanks again,
Steve

C++ProgrammierenWindows APIMartin Richter - Sa 25 Jun 2011 18:46

Wir haben ein Stück Code, dass verhindern soll, dass ein Programm zweimal gestartet werden kann.
Dieser basiert auf einem Mutex und einer Memory Mapped File, mit der man sich auch das Fenster-Handle einer bereits gestarteten Instanz besorgen kann.

Nun gelang es einem unserer Händler aber dennoch dieses Programm zweimal in einer Session zu starten und zwar auf folgendem Weg:

  1. Er startet die Software mit dem normalen Link auf dem Desktop, der durch das Installationsprogramm angelegt wurde.
  2. Er öffnen eine Console mit CMD.EXE und wechselt in das Verzeichnis, gibt den Programmnamen ein und das Programm startet erneut. 😮

Die Ursache ist war wie folgt:

  1. Der Mutex den wir intern verwendet haben nutzte den Dateinamen der EXE. Der Name des Mutex wird unter Anderem auch durch GetModuleFileName ermittelt.
  2. Der Dateiname der EXE, wenn sie als Verknüpfung gestartet wird ist „XYZ.exe“ (so wie die Datei auch auf der Festplatte heißt) und das liefert auch GetModuleFileName als Ergebnis.
  3. Der Dateiname, den GetModuleFileName liefert, wenn man das Programm aus CMD.EXE startest ist exakt so wie man es eintippt, also z.B. „xyz.exe“. Erstaunlich.
  4. Da der Mutex einen Namen case sensitiv behandelt (was ich nicht vermutet hätte und erst mit staunenden Augen nachgelesen habe), wurde das bereits gestartete Programm nicht erkannt und eine zweite Instanz gestartet.

Was schreiben wir uns also hinter die Löffel für die Zukunft:
a) GetModuleFileName liefert nicht den „exakten“ Dateinamen (obwohl ich es anders erwartet hätte)!
b) Mutexe sind case sensitiv wie auch Events (obwohl ich hier eine Behandlung wie bei einem Dateinamen erwartet habe)!
c) Manche Erwartungen trügen… 😉

HardwareSoftwareToolsWindows 7Martin Richter - Di 15 Mrz 2011 20:14

Ich hatte nach der Installation von Windows 7 auf einem meiner Rechner ein eigentümliches Problem:

Auf diesem Rechner wie auf auf zwei anderen meiner Rechner benutze ich eine Microsoft Keyboard-Maus Kombination. Entsprechend ist auf den Rechnern auch Microsoft IntelliType und IntelliPoint installiert.

Alles lief beim Update von Windows 7 glatt. Aber nach dem Neustart des Systems bekam ich einen UAC Prompt und es wurde gemeldet, dass ein neuer USB Treiber für die Microsoft Tastatur installiert werden müsste. Also OK.

Aber beim nächsten Neustart wieder die gleiche Meldung, ein detailierter Blick auf den Treiber der angefordert wurde ergab folgende Info:

rundll32.exe C:\Windows\system32\newdev.dll,pDiDeviceInstallAction \\.\pipe\PNP_Device_Install_Pipe_1.{541e93b9-2da1-4d96-91e1-68472a06f5a9} „usb\vid_045e&pid_00e3&mi_00\7&13cc06b7&0&0000“

Neuinstallation/Reparaturinstalltion der IntelliType Software nützte nichts.

Erst als ich die Software komplett entfert hatte und dann eine Neuinstalltion durchgeführt habe verschwand diese lästige Meldung.

OfficeProgrammierenSoftwareSupportVistaVista / Windows 7WindowsWindows 7Martin Richter - Sa 21 Aug 2010 10:16

 Wer kennt das nicht: Da hat man ein deutsches Microsoft-Produkt und bekommt eine Fehlermeldung, auf die Google nichts ausspuckt. Scheinbar ein seltener Fehler. Oder evtl. benutzen viel mehr Anwender die englische Version eines Entwicklerproduktes.

Was nun? Ja wenn man genau wüsste wie die selbe Meldung in englisch lautet, besonders wenn man keine Fehlernummer oder keine ID aus dem Ereignisprotokoll hat…

Die Lösung für MSDN Nutzer ist einfacher als man denkt:
Es gibt die Glossaries, d.h. die entsprechenden Übersetzungstabellen komplett zum Download ❗

In der entsprechenden ZIP-Datei befinden sich 276 csv Dateien mit allen möglichen Produkten. Das schließt die Windows Server Produkte ein, wie auch VisualStudio.
Alleine die Windows 7 Datei umfasst 56 Megabyte an Texten.

ProgrammierenSonstigesWindows APIMartin Richter - Sa 23 Jan 2010 20:39

Was macht man, wenn man keine Wait-Funktionen verwenden will, aber dennoch möchte, dass ein anderer Thread weiterarbeiten kann. Zum Beispiel, weil man einen Spinlock implementieren will.

Nun es gibt insgesamt vier Methoden die durch das Netz geistern.
Ich gehe mal der Häufigkeit nach, die so in manchen Code-Samples finde:

1. __noop;

Wenn der Lock kurz ist, scheint es das beste zu sein, einfach die Schleife weiterlaufen zu lassen und zu hoffen, dass der ein Thread auf einem anderen Prozessor, die Ressource freigibt. Das eignet sich wirklich nur, wenn die Zeitdauer der Sperre als extrem kurz anzusehen ist und eine hohe Anzahl von Prozessoren zur Verfügung steht.
Nach allen Test, die ich gemacht habe, sollte man aber von dieser Art des Wartens bei einem Spinlock absehen. Es schiebt die Leistung des Kerns auf 100% und bringt nichts.

2.  Sleep(0);

Lies sich gut. Schlafe aber eben nicht lange. Man hat auch schon irgendwo gelesen, dass durch diese Methode der Rest der Zeitscheibe dieses Threads aufgegeben wird und ein anderer Thread an die Reihe kommt.
Leider stimmt das nicht ganz ❗
Liest man die Doku genau steht da aber:

A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution.

😮 Threads mit höherer oder niedriger Prio haben also nichts davon.

Besonders eklig wird das ganze gerade wenn man Threads unterschiedlicher Prio hat, die hier gegeneinander laufen. Sleep(0); führt in diesem Fall zu einerunnötigen Prozessorlast und eben nicht dazu, dass die Zeitscheibe abgegeben wird. Der Prozess kommt sofort wieder an die Reihe und spin-t weiter.

3. SwitchToThread();

OK. Seit Windows 2000 gibt es diese nette neue Funktion. Damit wird ein anderer Thread aktiv. Egal was für eine Prio er hat. Aber auch diese Funktion tut evtl. nicht genau das was man will.
Auch hier stecken die Tücken im Detail der Doku:

The yield of execution is limited to the processor of the calling thread. The operating system will not switch execution to another processor, even if that processor is idle or is running a thread of lower priority.

Sollte also der Thread, auf den man wartet auf dem anderen Prozessor laufen, so profitiert der nicht von dem Aufruf von SwitchToThread.

4. Sleep(1):

Hiermit erreicht man wirklich was man möchte. Man gibt seine Timeslice auf und erstmal sind die anderen dran.

Mein persönliches Fazit:

Nach meinen Recherchen ist Sleep(1); der vernünftigste Weg seine Zeitscheibe abzugeben. Und nach meinem Dafürhalten ist ein __noop; strickt zu vermeiden. Die Performance ist grottenschlecht.
Das ganze Verhalten hängt extrem auch von den Umständen ab: Zahl der Theads, Häufigkeit der Kollision, Anzahl verfügbare Prozessoren, Verteilung der Prioritäten, Allgemeine Belastung des Systems, Zeitdauer der Sperre etc.

Ich habe mit einigen Parametern gespielt und auch ein kleines Sample gebaut, dass alle 4 oben genannten Funktionen durchprobiert und in dem man auch mit anderen Faktoren (Priorität etc.) spielen kann.
Es zeigte sich, dass Sleep(1); am effektivsten war. Aber dicht auf gefolgt von Sleep(0);, was mich doch etwas überraschte.

Allerdings führen schon kleinste Änderungen (Lockdauer, Zahl der Prozessoren, Spielen mit der Priorität) zu anderen Ergebnissen.
Interessant ist vor allem das Spielen mit den Prioritäten. Man soll nicht glauben, das ein Thread selbst mit niedrigster Prio noch relativ häufig Arbeit bekommt.

Viel Spaß beim Spielen mit dem Code SleepTest

C++ProgrammierenVS 2008VS 2010VS-Tipps&TricksWindows APIMartin Richter - Mo 21 Dez 2009 20:05

Wer sich schon durch die Windows Header gekämpft hat um herauszufinden warum welche Definition einer Struktur oder Funktion in irgend einer Windows Version so oder gar nicht vorhanden ist, der weiß auch wie einem #if, #elif, #else und #endif das Leben schwer machen können, was die Orientierung betrifft.

Netterweise hilft einem eine Funktion, die man nur von Blöcken und verschachtelten Funktionen her kennt Strg+´ (Edit.GotoBrace). Wichtig! Man darf nicht auf der Variable oder Bedingung stehen, sondern muss auf dem Schlüsselwort stehen.

Wenn man auf einer Präprozessor Direktive kann man mit den Tasten die einem zur passenden Klammer bringt zur nachfolgenden Direktive. Und mit dem Festhalten der Umschalttaste kann man den entsprechenden Block auch markieren.

InstallationSoftwareVistaWindowsWindows 7Martin Richter - So 01 Nov 2009 20:48

Nachdem ich vor einigen Tagen ein Update auf meinen Vista Rechner auf Windows 7  durchgeführt habe, sind mir zwei versteckte Ordner im Rootverzeichnis auf meiner Festplatte aufgefallen, die nicht klein sind.

Durch eingeschränkte Rechte hat man normalerweise keinen Zugriff, aber wenn man eine elevated Session mit dem Explorer startet kann man herausbekommen was sie beinhalten:

$WINDOWS.~Q    2200 MB (2.364.075.683 Bytes)
$INPLACE.~TR    471 MB (  494.284.806 Bytes)

Die Dateien in diesem Ordner schienen auf den ersten Blick irgendwas mit dem Update zu tun zu haben.

  • Der erste Schritt: Mal in der Systemsteuerung nachsehen ob man dort etwas deinstallieren kann. Nada.
  • Zweiter Blick: Starten der Datenrägerbereinigung. Auch nichts auffälliges.
  • Dritter Versuch: Starten der Datenträgerbereinigung als Administrator. Bingo ❗

Siehe da:

Datenträgerbereinigung

Zwei Dateigruppen finden sich:
Beim Window-Upgrade verworfene Dateien – und –
Protokolldateien für Windows-Upgrades

Anhaken und Schwupps sind 3GB mehr Plattenplatz da…

Nächste Seite »