Discussion:
Änderung des PATH für DLL-Zugriff aktualisieren?
(zu alt für eine Antwort)
Edzard Egberts
2015-02-02 16:03:12 UTC
Permalink
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl

SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);

dazu führen, dass das System den neuen Pfad benutzt. Mit SET kann ich
den neuen Pfad zwar sehen (command prompt), aber eine DLL, die über den
neuen Pfad gefunden werden soll, wird erst nach einem Neustart gefunden.

Muss man die Suche nach DLLs mit einem anderen Befehl anstoßen, oder ist
der Versuch mit WM_WININICHANGE falsch? Das wird ja an offene Fenster
gesendet, muss da noch irgend ein Systemaufruf gestartet werden?
Edzard Egberts
2015-02-02 16:13:30 UTC
Permalink
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt. Mit SET kann ich
den neuen Pfad zwar sehen (command prompt), aber eine DLL, die über den
neuen Pfad gefunden werden soll, wird erst nach einem Neustart gefunden.
Muss man die Suche nach DLLs mit einem anderen Befehl anstoßen, oder ist
der Versuch mit WM_WININICHANGE falsch? Das wird ja an offene Fenster
gesendet, muss da noch irgend ein Systemaufruf gestartet werden?
Aha, ich glaube, ich habe es gerade noch gefunden - die Funktion heißt
SetDllDirectory():

https://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx

Morgen mal sehen, ob das klappt...
Stefan Kanthak
2015-02-02 18:09:12 UTC
Permalink
[ DLL ueber PATH laden ]
Post by Edzard Egberts
Aha, ich glaube, ich habe es gerade noch gefunden - die Funktion heißt
https://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx
Damit vermeidest Du (wie auch beim ueber "App Paths" gesetzten Pfad)
ganz nebenbei, dass ein poehser Wicht PATH auf ein Verzeichnis seiner
Wahl setzt und damit Deine Anwendung seine DLL laden und ausfuehren
laesst.

Ist dummerweise erst seit dem letzten Jahrtausend als "DLL preloading
attack" bekannt.

JFTR: CWD wird noch VOR dem PATH durchsucht.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Stefan Kanthak
2015-02-02 16:52:30 UTC
Permalink
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt.
Nein.
GRUNDLAGEN!

Der Broadcast informiert alle LAUFENDEN Anwendungen, die Nachrichten
empfangen (dazu muessen diese beispielsweise ein [ggf. unsichtbares]
Fenster geoeffnet haben) und auf WM_WININICHANGE auch reagieren, dass
diese das Environment neu auswerten sollen.

Neu gestartete Prozesse erhalten das (aktuelle) Environment von
CreateProcess*() ... ausser dessen Aufrufer uebergibt CreateProcess*()
ein selbstgebasteltes Environment, dass er NICHT aktualisiert hat.
Post by Edzard Egberts
Mit SET kann ich den neuen Pfad zwar sehen (command prompt),
NICHT in einer bereits laufenden Eingabeaufforderung!
CMD.EXE reagiert auf WM_WININICHANGE nicht mit Neuauswertung des
Environment.
Post by Edzard Egberts
aber eine DLL, die über den neuen Pfad gefunden werden soll, wird erst
nach einem Neustart gefunden.
Die Anwendung, die diese laden soll, verarbeitet ganz offensichtlich
WM_WININICHANGE auch nicht!
Post by Edzard Egberts
Muss man die Suche nach DLLs mit einem anderen Befehl anstoßen, oder ist
der Versuch mit WM_WININICHANGE falsch? Das wird ja an offene Fenster
gesendet, muss da noch irgend ein Systemaufruf gestartet werden?
Senden alleine genuegt nicht, der Empfaenger muss RICHTIG reagieren!
S.o.

JFTR: lass die Finger vom globalen PATH.
Definiere den PATH nur fuer die betroffene(n) Anwendung(en),
die diese DLL laden sollen:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\program.exe]
@="<voller Pfad zu program.exe>"
"Path"="..." ; wird am Anfang von PATH eingefuegt und an program.exe uebergeben

Weiterer Vorteil: Start->Ausfuehren findet program.exe auch ohne
PATH!
Das funktioniert aber erst seit NT4 und Wintendo 95.-P

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-02 18:21:57 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt.
Nein.
GRUNDLAGEN!
Der Broadcast informiert alle LAUFENDEN Anwendungen, die Nachrichten
empfangen (dazu muessen diese beispielsweise ein [ggf. unsichtbares]
Fenster geoeffnet haben) und auf WM_WININICHANGE auch reagieren, dass
diese das Environment neu auswerten sollen.
So etwas habe ich mir schon gedacht. :o)
Post by Stefan Kanthak
NICHT in einer bereits laufenden Eingabeaufforderung!
CMD.EXE reagiert auf WM_WININICHANGE nicht mit Neuauswertung des
Environment.
Das kann ich bestätigen.
Post by Stefan Kanthak
Die Anwendung, die diese laden soll, verarbeitet ganz offensichtlich
WM_WININICHANGE auch nicht!
Nö, die startet noch nicht mal, weil sie ihre DLLs nicht findet.
Post by Stefan Kanthak
Senden alleine genuegt nicht, der Empfaenger muss RICHTIG reagieren!
Genau, und Windows reagiert gar nicht!
Post by Stefan Kanthak
JFTR: lass die Finger vom globalen PATH.
Definiere den PATH nur fuer die betroffene(n) Anwendung(en),
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\program.exe]
@="<voller Pfad zu program.exe>"
"Path"="..." ; wird am Anfang von PATH eingefuegt und an program.exe uebergeben
Weiterer Vorteil: Start->Ausfuehren findet program.exe auch ohne
PATH!
Das verstehe ich überhaupt nicht. Für <program.exe> lege ich Links an,
das kommt gar nicht in den Pfad. Da müssen nur die DLLs rein, die mein
Programm für meinen Lieblingstreiber benötigt. Da bin ich gerade mit
einem "Hidden Install" dran, so dass der Kunde nicht sieht, welche
Hardware wir verwenden. Ich halte ja nichts von so einer
Geheimniskrämerei, allerdings ist es mir recht egal, womit ich mein
Gehalt verdiene...
Post by Stefan Kanthak
Das funktioniert aber erst seit NT4 und Wintendo 95.-P
Neuerdings compiliere ich mit #define für Windows-NT ab 5.0 ("#define
WINNT 005" oder so ähnlich). Bin schon ein bisschen lernfähig
(*SCHULTERKLOPF!*). ;o)
Stefan Kanthak
2015-02-02 20:19:51 UTC
Permalink
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt.
Nein.
GRUNDLAGEN!
Der Broadcast informiert alle LAUFENDEN Anwendungen, die Nachrichten
empfangen (dazu muessen diese beispielsweise ein [ggf. unsichtbares]
Fenster geoeffnet haben) und auf WM_WININICHANGE auch reagieren, dass
diese das Environment neu auswerten sollen.
So etwas habe ich mir schon gedacht. :o)
Post by Stefan Kanthak
NICHT in einer bereits laufenden Eingabeaufforderung!
CMD.EXE reagiert auf WM_WININICHANGE nicht mit Neuauswertung des
Environment.
Das kann ich bestätigen.
Post by Stefan Kanthak
Die Anwendung, die diese laden soll, verarbeitet ganz offensichtlich
WM_WININICHANGE auch nicht!
Nö, die startet noch nicht mal, weil sie ihre DLLs nicht findet.
Dann startest Du sie wohl aus einem laufenden CMD.EXE: der Kommandoprozessor
frickelt das Environment selbst zusammen. Das muss er auch, damit die dort
gesetzten Variablen "vererbt" werden!

man "shell"

Starte die Anwendung ueber Start->Ausfuehren: der Windows Explorer macht's
richtig.
Post by Edzard Egberts
Post by Stefan Kanthak
Senden alleine genuegt nicht, der Empfaenger muss RICHTIG reagieren!
Genau, und Windows reagiert gar nicht!
Welches Windows?
Der Windows Explorer reagiert selbstverstaendlich darauf!
Post by Edzard Egberts
Post by Stefan Kanthak
JFTR: lass die Finger vom globalen PATH.
Definiere den PATH nur fuer die betroffene(n) Anwendung(en),
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\program.exe]
@="<voller Pfad zu program.exe>"
"Path"="..." ; wird am Anfang von PATH eingefuegt und an program.exe uebergeben
Weiterer Vorteil: Start->Ausfuehren findet program.exe auch ohne
PATH!
Das verstehe ich überhaupt nicht.
Dann lies die Kapitel zu "Registering your application ..." in MSDN!
Ersatzweise die 20 Jahre alte Dokumentation "Designed for Windows".
Post by Edzard Egberts
Für <program.exe> lege ich Links an,
Nein. Verknuepfungen alias "shortcuts".
Die werden vom selben Windows Explorer ausgefuehrt^Winterpretiert wie
die Registry-Eintraege unter "App Paths".

Trage dort beispielsweise
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Cmd.exe]
"Path"="X:\\Dummy;Y:\\FooBar"
ein; dann Start->Ausfuehren CMD.EXE /K Set PATH

Merkst Du was?

Du darfst CMD.EXE auch ueber die Verknuepfung im Startmenue starten
und "Set P" ausfuehren: auch dort siehst Du den neuen PATH!

[...]

Stefan

PS: fuer's Schulterklopfen wuensche ich mir manchmal einen scharfen
Gegenstand, horizontal gefuehrt.-P
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-03 08:25:40 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt.
Aha, daran lag es: Ich habe den neuen Pfad als eigene Variable
"OOI_HOME" definiert und dann als %OOI_HOME% in den PATH eingefügt. Das
Ganze im "Klartext" eingetragen, also den kompletten Pfad und plötzlich
funktioniert das mit dem WM_WININICHANGE. Das lag also am Ersetzen der
Variablen, das funktioniert scheinbar nur beim Booten.
Post by Stefan Kanthak
Der Windows Explorer reagiert selbstverstaendlich darauf!
Jetzt ja.
Post by Stefan Kanthak
Dann lies die Kapitel zu "Registering your application ..." in MSDN!
Mal geguckt, ist mir viel zu kompliziert und dazu noch überflüssig. Als
ob ein Kunde den Programmname *eintippt*, das wäre ja etwas ganz neues!
Außerdem geht es nicht darum, das Programm zu finden, sondern die DLLs
müssen weitere DLLs finden. Und dafür kann ich nichts, weil ich alles
was geht statisch linke.
Post by Stefan Kanthak
Post by Edzard Egberts
Für <program.exe> lege ich Links an,
Nein. Verknuepfungen alias "shortcuts".
Mit der Endung ".lnk" und Link ist neudeutsch für Verknüpfung. ;o)
Post by Stefan Kanthak
PS: fuer's Schulterklopfen wuensche ich mir manchmal einen scharfen
Gegenstand, horizontal gefuehrt.-P
Pff, hört sich irgendwie nicht so Ed-Freundlich an! Wer kann sich schon
"_WIN32_WINNT=0x0500" merken? Aber wenn es Dich tröstet - ich bin hier
sowieso der Einzige, der mir auf die Schulter klopft! ;o(
Stefan Kanthak
2015-02-03 12:33:01 UTC
Permalink
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt.
Aha, daran lag es: Ich habe den neuen Pfad als eigene Variable
"OOI_HOME" definiert und dann als %OOI_HOME% in den PATH eingefügt. Das
Ganze im "Klartext" eingetragen, also den kompletten Pfad und plötzlich
funktioniert das mit dem WM_WININICHANGE. Das lag also am Ersetzen der
Variablen, das funktioniert scheinbar nur beim Booten.
Es funktioniert per ZUFALL (L'O' < L'P')!
Wenn OOI_HOME nicht existiert oder aufgeloest werden kann (die
Umgebungsvariablen werden HAEUFIG in alphabetisch sortierter
Reihenfolge abgearbeitet) wenn PATH zusammengesetzt wird faellst Du
ebenfalls auf die Nase!
Post by Edzard Egberts
Post by Stefan Kanthak
Der Windows Explorer reagiert selbstverstaendlich darauf!
Jetzt ja.
Post by Stefan Kanthak
Dann lies die Kapitel zu "Registering your application ..." in MSDN!
Mal geguckt, ist mir viel zu kompliziert und dazu noch überflüssig. Als
ob ein Kunde den Programmname *eintippt*, das wäre ja etwas ganz neues!
Außerdem geht es nicht darum, das Programm zu finden, sondern die DLLs
müssen weitere DLLs finden.
LIES NOCHMAL, was ich schrieb, GAAANZ langsam und aufmerksam.

[...]

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Stefan Kanthak
2015-02-03 12:52:31 UTC
Permalink
Post by Edzard Egberts
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt.
Aha, daran lag es: Ich habe den neuen Pfad als eigene Variable
"OOI_HOME" definiert
Verwendest Du diesen beispielsweise in SetDllDirectory()?

AUTSCH!
Gratuliere, Du hast (nicht nur) mir gerade den Haustuerschluessel zu
den Systemen Deiner Kunden in die Hand gedrueckt!

Hoer auf, UNSICHERE Software zusammenzufrickeln!
Such Dir einen anstaendigen Job.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-03 13:59:11 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt.
Aha, daran lag es: Ich habe den neuen Pfad als eigene Variable
"OOI_HOME" definiert
Verwendest Du diesen beispielsweise in SetDllDirectory()?
Nein, ich verwende SetDllDirectory() gar nicht.
Post by Stefan Kanthak
AUTSCH!
Gratuliere, Du hast (nicht nur) mir gerade den Haustuerschluessel zu
den Systemen Deiner Kunden in die Hand gedrueckt!
Hoer auf, UNSICHERE Software zusammenzufrickeln!
Mache ich doch gar nicht! Ich baue einen Installer _für_einen_Treiber_,
der folgendem Auszug des zugehörigen "Programmers Manual" umsetzt:

"
If you choose to install OmniDriver on your end-user’s computer without
requiring them to run a separate OmniDriver installation, use the
following procedure.

Procedure
1. Copy the following directories (and everything beneath them) to your
customer’s PC:
OOI_HOME
_jvm (this directory must be placed on a peer level with the OOI_HOME
directory)
ezusb_driver (32-bit Windows platform only)
winusb_driver (64-bit Windows platform only)
labview (optional: if your application was written in LabVIEW)
2. Define the OOI_HOME environment variable. Give it a value like:
C:\Program Files\Ocean Optics\OmniDriver\OOI_HOME
Essentially, set this variable to the location of the OOI_HOME directory.
3. Add the pathname of the OOI_HOME directory to your systems PATH
environment variable.
4. On 64-bit Windows systems: cd into the winusb_driver folder and issue
the command
dpinst64.exe q /lm /sa
This installs the signed WinUSB driver files into the Windows system
area. As a result, when you plug in your spectrometer, it will
automatically find and install the required driver.
"

Ich kann nichts dafür, dass ich das machen muss und das klappt hinten
und vorne nicht. Für Win7-32bit habe ich das zurechtgefrickelt (mit
Zusätzen wie WININICHANGE und Direktkopie der *.inf/*.sys in die
entsprechenden Verzeichnisse), bei Win7-64bit habe ich gerade die
nervende Situation, das mein Programm läuft und sich auch die Hardware
installiert, aber das Programm dann die Hardware nicht findet. Nehme ich
den "Komplett-Installer" (den ich laut $CHEF nicht nehmen darf, weil da
ein anderer Firmenname drauf steht), geht das dann plötzlich doch. Ich
könnte den ganze Scheiß dieser Firma zu Klump schlagen, aber die
Hardware ist auch noch *teuer*!

*Meine* Software macht nichts anderes, als einen C-Wrapper zu linken,
*der* braucht dann vcredistributable 2008/2010, java und die ganzen
Pfade. Also ich bin hier nicht der Idiot!
Stefan Kanthak
2015-02-03 14:53:12 UTC
Permalink
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Edzard Egberts
Wenn ich unter Win7 32bit in der Registry/Environment den PATH geändert
habe, sollte meines Wissens der Befehl
SendMessageTimeoutA(HWND_BROADCAST, WM_WININICHANGE, 0, (LPARAM)
"Environment", SMTO_ABORTIFHUNG, 2000, 0);
dazu führen, dass das System den neuen Pfad benutzt.
Aha, daran lag es: Ich habe den neuen Pfad als eigene Variable
"OOI_HOME" definiert
Verwendest Du diesen beispielsweise in SetDllDirectory()?
Nein, ich verwende SetDllDirectory() gar nicht.
In <news:mao7pb$lo7$***@gwaiyur.mb-net.net> wolltest Du es verwenden!
Ich schrieb aber "beispielsweise": sobald Du %OOI_HOME% im globalen
PATH verwendest machst Du das GESAMTE System angreifbar.
Post by Edzard Egberts
Post by Stefan Kanthak
AUTSCH!
Gratuliere, Du hast (nicht nur) mir gerade den Haustuerschluessel zu
den Systemen Deiner Kunden in die Hand gedrueckt!
Hoer auf, UNSICHERE Software zusammenzufrickeln!
Mache ich doch gar nicht! Ich baue einen Installer _für_einen_Treiber_,
Falsch.
Die Installation von Treibern ist AUSSCHLIESSLICH per Geraetemanager
(genauer: den entsprechenden Windows-Schnittstellen) moeglich! Diese
Schnittstellen interpretieren vom Hersteller des Treibers zu liefernde
*.INF.

VERWENDE DIESEN KANONISCHEN WEG! Hoer auf rumzufrickeln!

JFTR: nein, Du musst den Geraetemanager nicht direkt aufrufen:
DEVCON.EXE oder DPINST.EXE oder RUNDLL32.EXE SETUPAPI.DLL,...
machen das fuer Dich.
Post by Edzard Egberts
"
If you choose to install OmniDriver on your end-user’s computer without
requiring them to run a separate OmniDriver installation, use the
following procedure.
Procedure
1. Copy the following directories (and everything beneath them) to your
OOI_HOME
_jvm (this directory must be placed on a peer level with the OOI_HOME
directory)
ezusb_driver (32-bit Windows platform only)
winusb_driver (64-bit Windows platform only)
labview (optional: if your application was written in LabVIEW)
C:\Program Files\Ocean Optics\OmniDriver\OOI_HOME
Essentially, set this variable to the location of the OOI_HOME directory.
3. Add the pathname of the OOI_HOME directory to your systems PATH
environment variable.
Frage

1. wieso sie diesen Bloedsinn schreiben;

2. wozu ihr Zeux OOI_HOME im GLOBALEN Pfad braucht;

3. wieso sie damit die Systeme ALLER Ihrer Kunden angreifbar machen!

[...]
Post by Edzard Egberts
Ich kann nichts dafür, dass ich das machen muss
Doch.
Punkt 3 dieser "Anleitung" ist VOELLIGER Schwachsinn und vor allem
UNNOETIG!

[...]
Post by Edzard Egberts
*Meine* Software macht nichts anderes, als einen C-Wrapper zu linken,
*der* braucht dann vcredistributable 2008/2010, java und die ganzen
Pfade. Also ich bin hier nicht der Idiot!
Doch: Du folgst ohne Nachdenken einer schwachsinnigen Anleitung, die
Sicherheitsluecken einbaut.

Nochmal: OOI_HOME wird NUR von der/n Anwendung(en) dieser Klitsche im
PATH gebraucht! Lege fuer die Anwendung(en) dieser Klitsche den/die
Registry-Eintraege

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\program.exe]
"Path"="<Pfad von OOI_HOME>"
(oder "Path"=expand:"%OOI_HOME%")

an. Dieser Eintrag wird beim Start von "program.exe" per ShellExecute*(),
d.h. allen Aufrufen durch den Windows Explorer, also Doppelklick, Start->
Ausfuehren, per *.lnk oder *.pif und auch "CMD.EXE /K Start program.exe"
ausgewertet und setzt den dort angegebenen "Path" an den Anfang der
PATH-Umgebungsvariable fuer DIESES Programm!

ShellExecute*() braucht auch keinen Neustart des Systems...
Das oeffnet ganz bloede bei jedem Aufruf diesen Registry-Schluessel:
wenn er fehlt macht es weiter, wenn er existiert wertet es ihn aus.

Statt [HKEY_LOCAL_MACHINE\SOFTWARE\...] kannst Du auch
[HKEY_CURRENT_USER\Software\...] verwenden.

wehret den Anfaengern!
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-03 16:12:17 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Nein, ich verwende SetDllDirectory() gar nicht.
Ja, dann habe ich aber herausgefunden, dass mir das nichts bringt und
das Problem woanders liegt.
Post by Stefan Kanthak
Ich schrieb aber "beispielsweise": sobald Du %OOI_HOME% im globalen
PATH verwendest machst Du das GESAMTE System angreifbar.
Post by Edzard Egberts
Post by Stefan Kanthak
Hoer auf, UNSICHERE Software zusammenzufrickeln!
Ich habe kein Sicherheitsproblem mit Windows - die beiden Instanzen
laufen bei mir in einer Virtuellen Maschine unter CentOS und werden vor
fast jedem Start auf "Installation + Updates" zurückgesetzt. Jeder, der
Windows anders verwendet, soll sich bei Sicherheitsproblemen an den
PC-Hersteller wenden, die interessieren weder mich noch Microsoft.
Post by Stefan Kanthak
DEVCON.EXE oder DPINST.EXE oder RUNDLL32.EXE SETUPAPI.DLL,...
machen das fuer Dich.
dpinst.exe verwende ich hier - die Treiberinstallation funktioniert ja,
nur die Software findet die Hardware nicht. Ich habe den Verdacht, dass
das Verzeichnis festgelegt ist, denn ein "nachbauen von Hand" der
Originalinstallation funktioniert. Da muss ich jetzt schrittweise das
Verzeichnis ändern und schieben...
Post by Stefan Kanthak
1. wieso sie diesen Bloedsinn schreiben;
Wüßte ich auch gerne, in dem Handbuch ist einiges, was die bestimmt noch
nie getestet haben, das "Custom Branding" funktioniert nämlich auch rein
gar nicht.
Post by Stefan Kanthak
2. wozu ihr Zeux OOI_HOME im GLOBALEN Pfad braucht;
Da sind massenhaft DLLs drinnen und das _jvm-Zeugs wird auch gebraucht.
Warum jemand einen C-Wrapper auf einem Java-Treiber aufbaut, ist mir
völlig schleierhaft.
Post by Stefan Kanthak
3. wieso sie damit die Systeme ALLER Ihrer Kunden angreifbar machen!
Das ist denen wahrscheinlich auch egal, so lange die Hardware läuft.
Dass die nicht läuft ist nämlich mein Problem und nicht irgendein
Sicherheitsfeature.
Post by Stefan Kanthak
Lege fuer die Anwendung(en) dieser Klitsche den/die
Registry-Eintraege
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\program.exe]
"Path"="<Pfad von OOI_HOME>"
(oder "Path"=expand:"%OOI_HOME%")
an. Dieser Eintrag wird beim Start von "program.exe" per ShellExecute*(),
d.h. allen Aufrufen durch den Windows Explorer, also Doppelklick, Start->
Ausfuehren, per *.lnk oder *.pif und auch "CMD.EXE /K Start program.exe"
ausgewertet und setzt den dort angegebenen "Path" an den Anfang der
PATH-Umgebungsvariable fuer DIESES Programm!
Das probiere ich aus, wenn mein Problem gelöst ist, aber im Moment
bringt mir das rein gar nichts.
Stefan Kanthak
2015-02-03 17:20:09 UTC
Permalink
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Nein, ich verwende SetDllDirectory() gar nicht.
Ja, dann habe ich aber herausgefunden, dass mir das nichts bringt und
das Problem woanders liegt.
Post by Stefan Kanthak
Ich schrieb aber "beispielsweise": sobald Du %OOI_HOME% im globalen
PATH verwendest machst Du das GESAMTE System angreifbar.
Post by Edzard Egberts
Post by Stefan Kanthak
Hoer auf, UNSICHERE Software zusammenzufrickeln!
Ich habe kein Sicherheitsproblem mit Windows
Windows ist NICHT das Sicherheitsproblem.
Sondern Dein Versuch, (D)ein LOKALES Problem durch Setzen einer
GLOBALEN Variable zu loesen und damit eine globale Schwachstelle
einzubauen.

[...]
Post by Edzard Egberts
Post by Stefan Kanthak
2. wozu ihr Zeux OOI_HOME im GLOBALEN Pfad braucht;
Da sind massenhaft DLLs drinnen
Und die Programme nicht?!
Du weisst, dass Windows DLLs zuerst in dem Verzeichnis sucht, aus dem
die Anwendung geladen wurde?
Nochmal: wofuer muss %OOI_HOME% im GLOBALEN Pfad stehen?
Zum Laden der DLLs muss es UEBERHAUPT NICHT im Pfad stehen!
Post by Edzard Egberts
und das _jvm-Zeugs wird auch gebraucht.
Das steht aber NICHT im PATH!
Post by Edzard Egberts
Warum jemand einen C-Wrapper auf einem Java-Treiber aufbaut, ist mir
völlig schleierhaft.
Das hat vermutlich der Werkstudent verbrochen, den die Firma dieses
Zeux hat frickeln lassen: der konnte nur Java.
Post by Edzard Egberts
Post by Stefan Kanthak
3. wieso sie damit die Systeme ALLER Ihrer Kunden angreifbar machen!
Das ist denen wahrscheinlich auch egal, so lange die Hardware läuft.
"ignorance is bliss!"
Post by Edzard Egberts
Dass die nicht läuft ist nämlich mein Problem und nicht irgendein
Sicherheitsfeature.
Wieso baust Du dann vorsaetzlich eine GLOBALE Schwachstelle ein?

[...]

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-03 17:53:18 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Ich habe kein Sicherheitsproblem mit Windows
Windows ist NICHT das Sicherheitsproblem.
Na gut, das müssen wir nicht diskutieren! ;o)
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Stefan Kanthak
2. wozu ihr Zeux OOI_HOME im GLOBALEN Pfad braucht;
Da sind massenhaft DLLs drinnen
Und die Programme nicht?!
Da sind schon Programme drin, aber mein Programm hat ein eigenes
Verzeichnis.
Post by Stefan Kanthak
Du weisst, dass Windows DLLs zuerst in dem Verzeichnis sucht, aus dem
die Anwendung geladen wurde?
Ja. Die "Search Priority" habe ich heute schon ein halbes Dutzend mal
gesehen.
Post by Stefan Kanthak
Nochmal: wofuer muss %OOI_HOME% im GLOBALEN Pfad stehen?
Zum Laden der DLLs muss es UEBERHAUPT NICHT im Pfad stehen!
Wenn ich das herausgefunden habe, ist mein Problem vielleicht gelöst.
Post by Stefan Kanthak
Post by Edzard Egberts
und das _jvm-Zeugs wird auch gebraucht.
Das steht aber NICHT im PATH!
Nein, muss aber laut Handbuch "auf gleicher Ebene" wie das OOI_HOME
stehen, da erfolgt wahrscheinlich ein relativer Zugriff aus den DLLs
heraus. Wofür das gebraucht wird, kann ich Dir übrigens sagen: Der
C-Wrapper liefert Strings und Double-Arrays als Java-Objekte! In meinen
Augen eine reichlich überflüssige Abhängigkeit, da kannte wohl jemand
den C-Style nicht.
Post by Stefan Kanthak
Post by Edzard Egberts
Warum jemand einen C-Wrapper auf einem Java-Treiber aufbaut, ist mir
völlig schleierhaft.
Das hat vermutlich der Werkstudent verbrochen, den die Firma dieses
Zeux hat frickeln lassen: der konnte nur Java.
Ich hätte auf "Praktikant" getippt, aber "Werkstudent" ist tatsächlich
plausibler. :o)
Post by Stefan Kanthak
Wieso baust Du dann vorsaetzlich eine GLOBALE Schwachstelle ein?
Ich bin doch schon überzeugt: Wie gesagt, wenn es läuft probiere ich
Deine Variante aus. Aber vorher muss ich eben von der als funktionierend
bekannten Konfiguration ausgehen...
Stefan Kanthak
2015-02-03 19:05:40 UTC
Permalink
[...]
Post by Edzard Egberts
Post by Stefan Kanthak
Nochmal: wofuer muss %OOI_HOME% im GLOBALEN Pfad stehen?
Zum Laden der DLLs muss es UEBERHAUPT NICHT im Pfad stehen!
Wenn ich das herausgefunden habe, ist mein Problem vielleicht gelöst.
Deshalb frage ich ja, resp. weise ich darauf hin.
Bist Du denn sicher, dass Dein (woanders stehendes) Programm die
"richtigen" DLLs laedt?

Das protokolliert Windows fuer Dich sobald Du folgende Registry-
Eintraege setzt:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"LogFileName"="C:\\Windows\\System32\\LogFiles\\SAFER.Log"
"TransparentEnabled"=dword:00000002

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-04 09:34:24 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Stefan Kanthak
Nochmal: wofuer muss %OOI_HOME% im GLOBALEN Pfad stehen?
Zum Laden der DLLs muss es UEBERHAUPT NICHT im Pfad stehen!
Wenn ich das herausgefunden habe, ist mein Problem vielleicht gelöst.
Deshalb frage ich ja, resp. weise ich darauf hin.
Bist Du denn sicher, dass Dein (woanders stehendes) Programm die
"richtigen" DLLs laedt?
Na ja, ohne den Pfad findet es keine DLLs und beschwert sich.

Das Problem lag gar nicht mehr an den Pfaden, sondern an einer
NatUSBwin.dll, die in zwei Versionen vorliegt. Nachdem ich entdeckt
habe, dass mein grafischer "Meld-Diff" keine Binärdateien vergleicht,
hat ein Konsolen-Diff direkt den relevanten Unterschied ausgeworfen.
Peinlich, gibt eigentlich keinen Grund unter Linux ein grafisches Tool
zu verwenden! ;o)

Aber selbstverständlich schießt mir Microsoft noch in den Fuß: Beim
dpinst64.exe funktioniert die Option /LM für die Installation
unsignierter Treiber nicht ("für neuere Windows Versionen"), das geht
also nur, wenn man im Dialog 15x (der Installer soll mehrere Geräte
einrichten) "Unsignierten Treiber installieren" drückt. Gibt es dafür
eine Lösung? Werde jetzt erst einmal die anderen Sachen ausprobieren,
die Du aufgezählt hast.

Elende Schikane, das schreit irgendwie danach, aus möglichst großer Höhe
auf "Windows Sicherheit" zu scheißen: Wenn Microsoft auf Sicherheit Wert
legen würde, müssten die ihre Signaturen ja nicht unbedingt *verkaufen*.
Ist doch kein Wunder, dass niemand dafür Geld ausgeben will...
Stefan Kanthak
2015-02-04 10:52:14 UTC
Permalink
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Stefan Kanthak
Nochmal: wofuer muss %OOI_HOME% im GLOBALEN Pfad stehen?
Zum Laden der DLLs muss es UEBERHAUPT NICHT im Pfad stehen!
Wenn ich das herausgefunden habe, ist mein Problem vielleicht gelöst.
Deshalb frage ich ja, resp. weise ich darauf hin.
Bist Du denn sicher, dass Dein (woanders stehendes) Programm die
"richtigen" DLLs laedt?
~~~~~~~~~~~~~~~~
Post by Edzard Egberts
Na ja, ohne den Pfad findet es keine DLLs und beschwert sich.
Das Problem lag gar nicht mehr an den Pfaden, sondern an einer
NatUSBwin.dll, die in zwei Versionen vorliegt.
Ich hab's Dir unterstrichen!
Post by Edzard Egberts
Nachdem ich entdeckt
habe, dass mein grafischer "Meld-Diff" keine Binärdateien vergleicht,
Wirf es weg.
Das strunzdumme WINDIFF.EXE, das Microsoft seit etwa 20 Jahren mit
Visual C[++], Visual Studio, {Resource,Support,Software Development}
Kits auch umsonst anbietet, kann das.
Post by Edzard Egberts
hat ein Konsolen-Diff direkt den relevanten Unterschied ausgeworfen.
Peinlich, gibt eigentlich keinen Grund unter Linux ein grafisches Tool
zu verwenden! ;o)
Gibt es einen Grund, Software fuer Windows NICHT unter Windows zu
frickeln?
Post by Edzard Egberts
Aber selbstverständlich schießt mir Microsoft noch in den Fuß: Beim
dpinst64.exe funktioniert die Option /LM für die Installation
unsignierter Treiber nicht ("für neuere Windows Versionen"), das geht
also nur, wenn man im Dialog 15x (der Installer soll mehrere Geräte
einrichten) "Unsignierten Treiber installieren" drückt.
Frag die Verbrecher dieses Treibers, wieso sie ihn nicht signieren
lassen!
Post by Edzard Egberts
Gibt es dafür eine Lösung?
Selbstverstaendlich!
Keine x64-Variante von Windows einsetzen.
Microsoft hat vor 10 Jahren ALLE Frickelbuden und Entwickler informiert,
dass Treiber fuer NT6.x x64 signiert sein muessen.
Post by Edzard Egberts
Werde jetzt erst einmal die anderen Sachen ausprobieren, die Du
aufgezählt hast.
Elende Schikane, das schreit irgendwie danach, aus möglichst großer Höhe
auf "Windows Sicherheit" zu scheißen: Wenn Microsoft auf Sicherheit Wert
legen würde, müssten die ihre Signaturen ja nicht unbedingt *verkaufen*.
ARGH!
Signaturen sind KEIN Sicherheitsmerkmal.
Sie sind ein Identifizierungs- und Authentifizierungsmerkmal.
Post by Edzard Egberts
Ist doch kein Wunder, dass niemand dafür Geld ausgeben will...
Ach?
Laedst Du unter Linux *.ko unbekannter Herkunft?

MERKST DU WAS?

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-04 13:05:33 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Stefan Kanthak
Bist Du denn sicher, dass Dein (woanders stehendes) Programm die
"richtigen" DLLs laedt?
~~~~~~~~~~~~~~~~
Post by Edzard Egberts
Na ja, ohne den Pfad findet es keine DLLs und beschwert sich.
Das Problem lag gar nicht mehr an den Pfaden, sondern an einer
NatUSBwin.dll, die in zwei Versionen vorliegt.
Ich hab's Dir unterstrichen!
Na ja, die zwei Versionen hatten den gleichen Namen...
Post by Stefan Kanthak
Gibt es einen Grund, Software fuer Windows NICHT unter Windows zu
frickeln?
Zuerst einmal Systemunabhängigkeit und freie Wahl der
Entwicklungswerkzeuge - ich möchte keinesfalls davon abhängig sein,
welche Sau MS gerade durchs Dorf treibt. Dann waren die
MS-Development-Tools immer sauteuer und um ein MSDN-Abo kam man kaum
herum. Inzwischen gibt es zwar "Community Versionen", aber die sind
eingeschränkt und mit Nebenbedingungen zugepflastert - ich sehe es auf
gar keinen Fall ein, dass mir MS _irgend_etwas_ in Bezug auf Software,
die ich geschrieben habe, zu sagen hat, egal ob diese Firma nun 2 oder
2000 Mitarbeiter hat. Irgend ein Problem unter Windows zu lösen wird
immer zur unendlichen Geschichte, weil es für jedes Problem ein halbes
Dutzend unterschiedlicher und inkompatibler MS-Lösungen gibt und man
seit .NET sowieso nichts mehr findet. Debugging unter Windows mit
Linux-Tools ist auch eine Katastrophe, weil das Windows-Programmformat
scheinbar recht speziell ist. Die ganzen MS-Tools sind üblicherweise
überkomplexe eierlegende Wollmilchsäue mit kleineren Haken, die zu
tagelangen Workarounds führen, nachdem man erst einmal verstanden hat,
wie die überhaupt zu verwenden sind und dass der Fehler wirklich ein
Fehler ist. Wenn man z.B. die Anzahl der Methoden von .NET und der FLTK
vergleicht, ist der Unterschied offensichtlich (mehrere
Größenordnungen!). Außerdem ist Windows strunzlangsam und rappelt mit
der Festplatte - wenn ich das schon höre, bekomme ich Pickel! NTFS ist
nicht mehr unbedingt so zeitgemäß. Und es wird einfach nicht besser!

Unter Linux zu entwickeln macht dagegen einfach nur Spaß.
Post by Stefan Kanthak
Frag die Verbrecher dieses Treibers, wieso sie ihn nicht signieren
lassen!
Das macht doch *niemand*, ist wahrscheinlich zu teuer und zu aufwändig.
Post by Stefan Kanthak
Microsoft hat vor 10 Jahren ALLE Frickelbuden und Entwickler informiert,
dass Treiber fuer NT6.x x64 signiert sein muessen.
Vor 10 Jahren gab es aber noch kein funktionierendes NT6.x! Albtraum!
Wenn ich daran denke, wie sich bei einer Einweisung vor knapp 20 Leuten
beim Hochfahren das Vista zerlegte (nach einer Woche Testlauf) und ich
vor Publikum ein Downgrade durchführen musste (danach lief die Anlage
jahrelang störungsfrei). Selbst MS hat damals eingesehen, dass Windows
NT6 nicht benutzbar ist (und nichts draus gelernt).

Damals war ich auch Ansprechpartner für knapp 400 Kunden-PCs und kriege
heute noch Panikattacken, wenn ein Telefon klingelt (und Ärger mit
$CHEF, wenn ich einfach mal öfter nicht ans Telefon gehe). Ein Soldat
wäre wahrscheinlich mit PTBS in Rente geschickt worden. Ich musste mich
dagegen von so tollen Sachen, wie der Win-98-Speicherverwaltung in den
Wahnsinn treiben lassen, die bei Allozierung vieler kleiner Objekte
(z.B. ein Log) einfach mal abstürzte. Oder willkürlicher Änderung der
seriellen Schnittstelle, die plötzlich nicht mehr auf das Ende der
Übertragung warten konnte und meine Hardware unbrauchbar machte. Oder
dem All-Time-Feature, dass sich Windows beim Hochfahren final zerlegte.
Von Kundenproblemen ganz abgesehen ("Habe die ganzen gelben Kästchen
gelöscht - ist das ein Problem?" die Rede war von Ordnern im
Windows-Explorer).
Post by Stefan Kanthak
Signaturen sind KEIN Sicherheitsmerkmal.
Sie sind ein Identifizierungs- und Authentifizierungsmerkmal.
Also reine Schikane und Geldschneiderei, habe ich mir schon gedacht!

Ich bin es jetzt jedenfalls leid, soll der Kunde doch 15x klicken, mir
doch egal (warum nur ist mir beim googlen nach dem Problem das Wort
"idiots" öfter aufgefallen - einmal bestätigen könnte ja auch reichen!).
Und am PATH bastele ich auch nicht herum, Deine Lösung funktioniert doch
schon nicht mehr, wenn das Programm umbenannt wird, oder der Treiber mit
dem Originalprogramm nachinstalliert wird. Mein Programm muss aber
laufen, irgend welche Windows-Sicherheits-Features sind dagegen
eindeutig "Problem anderer Leute". Ich bin jetzt schon
_über_einen_Monat_ mit Windows-7-Anpassungen beschäftigt (dieser
Installer war zum Glück das letzte Problem), das geht auch nur, weil ich
hier im wissenschaftlichen Umfeld arbeite und mein Arbeitsplatz nicht
über kostendeckende Tätigkeit finanziert wird. Als Unternehmer würde ich
schon wieder völlig am Rad drehen...
Post by Stefan Kanthak
Laedst Du unter Linux *.ko unbekannter Herkunft?
MERKST DU WAS?
Ja, es geht hier nicht um unbekannte Herkunft, sondern um ordentlich
teure Geräte, die die Kunden haben wollen.
Stefan Kanthak
2015-02-04 13:37:01 UTC
Permalink
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Stefan Kanthak
Bist Du denn sicher, dass Dein (woanders stehendes) Programm die
"richtigen" DLLs laedt?
~~~~~~~~~~~~~~~~
Post by Edzard Egberts
Na ja, ohne den Pfad findet es keine DLLs und beschwert sich.
Das Problem lag gar nicht mehr an den Pfaden, sondern an einer
NatUSBwin.dll, die in zwei Versionen vorliegt.
Ich hab's Dir unterstrichen!
Na ja, die zwei Versionen hatten den gleichen Namen...
... lagen aber in VERSCHIEDENEN Verzeichnissen.
Sowas bezeichnet man seit etwa 50 Jahren als PFAD!
Post by Edzard Egberts
Post by Stefan Kanthak
Gibt es einen Grund, Software fuer Windows NICHT unter Windows zu
frickeln?
Zuerst einmal Systemunabhängigkeit und freie Wahl der
Entwicklungswerkzeuge - ich möchte keinesfalls davon abhängig sein,
welche Sau MS gerade durchs Dorf treibt.
Ach?
Und wovon bist Du jetzt abhaengig?
Von den VERALTETEN Header-Dateien des Win32-API, die MinGW mitbringt?
Muss ich weitermachen?
Post by Edzard Egberts
Dann waren die MS-Development-Tools immer sauteuer
Ich habe mir vor 16 Jahren mal ein VC6 fuer DM 200,- gekauft.
Ab 2003 gab's das kostenlose "Visual C++ Toolkit 2003", seit 2005
die "Visual Studio 2xyz Express Edition".
Die Platform SDKs sind seit dem letzten Jahrtausend kostenlos und
bringen (Cross-)Compiler etc. mit.
Post by Edzard Egberts
und um ein MSDN-Abo kam man kaum herum.
Seit ueber 10 Jahren kanst Du MSDN auf DVD herunterladen!

[...]
Post by Edzard Egberts
Wenn man z.B. die Anzahl der Methoden von .NET und der FLTK vergleicht,
ist der Unterschied offensichtlich (mehrere Größenordnungen!).
Aha. Du kennst den Unterschied zwischen .NET und FLTK?
Post by Edzard Egberts
Außerdem ist Windows strunzlangsam und rappelt mit
der Festplatte - wenn ich das schon höre, bekomme ich Pickel!
Letzteres goenne ich Dir.
Hier[tm] laeuft Windows genauso lahm wie Linux. Auf aelteren Rechnern
meist weniger lahm als ein Linux!
Post by Edzard Egberts
NTFS ist
nicht mehr unbedingt so zeitgemäß. Und es wird einfach nicht besser!
Unter Linux zu entwickeln macht dagegen einfach nur Spaß.
Dort sind nur die Baukloetze anders!
Post by Edzard Egberts
Post by Stefan Kanthak
Frag die Verbrecher dieses Treibers, wieso sie ihn nicht signieren
lassen!
Das macht doch *niemand*, ist wahrscheinlich zu teuer und zu aufwändig.
VOELLIG AHNUNGSLOS!
Such Dir einen Job, in dem Du keinen Flurschaden anrichtest.
Post by Edzard Egberts
Post by Stefan Kanthak
Microsoft hat vor 10 Jahren ALLE Frickelbuden und Entwickler informiert,
dass Treiber fuer NT6.x x64 signiert sein muessen.
Vor 10 Jahren gab es aber noch kein funktionierendes NT6.x! Albtraum!
Das war die ANKUENDIGUNG!
Damit sich Frickelbuden und deren frickelnde Entwickler (einer sitzt
vor Deinem Bildschirm) darauf einstellen koennen.

[ mehr PEBKAC ]
Post by Edzard Egberts
Post by Stefan Kanthak
Signaturen sind KEIN Sicherheitsmerkmal.
Sie sind ein Identifizierungs- und Authentifizierungsmerkmal.
Also reine Schikane und Geldschneiderei, habe ich mir schon gedacht!
Ich bin es jetzt jedenfalls leid, soll der Kunde doch 15x klicken, mir
doch egal (warum nur ist mir beim googlen nach dem Problem das Wort
"idiots" öfter aufgefallen - einmal bestätigen könnte ja auch reichen!).
Beschwer Dich bei den Verbrechern des Treibers resp. dessen *.INF.
Die sind UNFAEHIG! VOELLIG UNFAEHIG!
Post by Edzard Egberts
Und am PATH bastele ich auch nicht herum, Deine Lösung funktioniert doch
schon nicht mehr, wenn das Programm umbenannt wird,
AUTSCH!
Die armen Schweine, die dieses Zeux verwenden muessen, haben Schreib-
Rechte im Installationsverzeichnis und koennen/duerfen dort Dateinamen
aendern?
Post by Edzard Egberts
oder der Treiber mit dem Originalprogramm nachinstalliert wird.
Dann solltest Du dieses Originalprogramm nicht mitliefern!
Post by Edzard Egberts
Mein Programm muss aber laufen, irgend welche Windows-Sicherheits-
Features sind dagegen eindeutig "Problem anderer Leute".
JFTR: "ignorance is bliss!"

Du bist doch gar nicht ueber solche Sicherheits-Features gestolpert,
sondern nur ueber Deine eigenen Fuesse und Deine kaputten Werkzeuge!
"a fool with a tool is just a fool!"

[...]
Post by Edzard Egberts
Als Unternehmer würde ich schon wieder völlig am Rad drehen...
Niemand zwingt Dich, Software fuer Windows zu frickeln!
Post by Edzard Egberts
Post by Stefan Kanthak
Laedst Du unter Linux *.ko unbekannter Herkunft?
MERKST DU WAS?
Ja, es geht hier nicht um unbekannte Herkunft, sondern um ordentlich
teure Geräte, die die Kunden haben wollen.
1. welches *.ko liefert DIESER Hersteller denn?

2. viel Spass mit Linux und systemd und UEFI und "secure boot".

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-04 15:09:12 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Na ja, die zwei Versionen hatten den gleichen Namen...
... lagen aber in VERSCHIEDENEN Verzeichnissen.
Nein, die wurden vom originalen Installer in Abhängigkeit von der
Umgebung mit gleichem Namen im gleichen Verzeichnis aus
unterschiedlichen Quelle erzeugt.
Post by Stefan Kanthak
Und wovon bist Du jetzt abhaengig?
Von den VERALTETEN Header-Dateien des Win32-API, die MinGW mitbringt?
*Veraltet* ist saukomisch - Dir ist aber schon klar, dass vor kurzem
tausende von Leuten von einer *völlig veralteten* Windows-Version auf
eine *veraltete* Windows-Version umgestiegen sind? Veraltet funktioniert
wenigstens, guck' Dir mal die Marktanteile von Win8 an!
Post by Stefan Kanthak
Post by Edzard Egberts
Dann waren die MS-Development-Tools immer sauteuer
Ich habe mir vor 16 Jahren mal ein VC6 fuer DM 200,- gekauft.
Studentenversion? Bin mir ziemlich sicher, dass kommerziell im
vierstelligen Bereich lag.
Post by Stefan Kanthak
Ab 2003 gab's das kostenlose "Visual C++ Toolkit 2003"
Das war so ungefähr der Zeitpunkt, wo ich auf OpenSource umgestiegen
bin. Schreiend!
Post by Stefan Kanthak
Post by Edzard Egberts
Wenn man z.B. die Anzahl der Methoden von .NET und der FLTK vergleicht,
ist der Unterschied offensichtlich (mehrere Größenordnungen!).
Aha. Du kennst den Unterschied zwischen .NET und FLTK?
Klar, das eine ist ein gigantisches, völlig unbeherrschbares Framework,
das MS wahrscheinlich nie völlig fehlerfrei hin bekommt und hunderte
Megabyte zur Installation braucht, das andere ist klein, überschaubar,
leicht zu lernen und weitgehend fehlerfrei. Mal davon abgesehn, dass
.NET von Anfang an überflüssig war, weil es Java schon gab und nicht nur
auf Windows lief (Mono ignoriere ich mal großzügigerweise).
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Stefan Kanthak
Frag die Verbrecher dieses Treibers, wieso sie ihn nicht signieren
lassen!
Das macht doch *niemand*, ist wahrscheinlich zu teuer und zu aufwändig.
VOELLIG AHNUNGSLOS!
Für mich ist es Standard, dass man unter Windows die Installation nicht
signierter Treiber bestätigen muss. Seit heute weiß ich auch, warum das
so ist.
Post by Stefan Kanthak
Such Dir einen Job, in dem Du keinen Flurschaden anrichtest.
Ach was, ich stehe da auf den Schultern von Riesen, schließlich kann ich
weder für Windows, noch für diesen Treiber etwas. Der größte
Volksschädling ist doch sowieso Microsoft, ich darf gar nicht daran
denken, was die XP-Abkündigung gekostet hat, selbst in dieser kleinen
Klitsche kamen deutlich über tausend Euro zusammen (Neues Windows und
neue Software mit aktuellen Lizenzen). Außerdem bin ich sowieso nur
eingestellt worden, weil die Installation von Matlab-Programmen so
aufwändig ist und ich die in "C" umsetzen sollte. :o)
Post by Stefan Kanthak
Beschwer Dich bei den Verbrechern des Treibers resp. dessen *.INF.
Die sind UNFAEHIG! VOELLIG UNFAEHIG!
Na ja, das wird sich wohl kaum ändern, wenn ich mich beschwere. Außerdem
hört sowieso niemand auf mich.
Post by Stefan Kanthak
AUTSCH!
Die armen Schweine, die dieses Zeux verwenden muessen, haben Schreib-
Rechte im Installationsverzeichnis und koennen/duerfen dort Dateinamen
aendern?
Klar, traditionell sind Windows-User doch immer noch als Admin
unterwegs. Außerdem dachte ich eher an das installierte Verzeichnis.
Post by Stefan Kanthak
Post by Edzard Egberts
Als Unternehmer würde ich schon wieder völlig am Rad drehen...
Niemand zwingt Dich, Software fuer Windows zu frickeln!
Die frickele ich doch auch unter Linux zusammen (sonst würde ich mir
sofort einen anderen Job suchen) und die ist sowieso gerade nicht das
Problem, sondern die Windows- und Treiberinstallation. Normalerweise
kann man meine Software irgendwo hin kopieren und mit Doppelklick
ausführen, aber einen Treiber kann ich eben nicht statisch linken.
Post by Stefan Kanthak
2. viel Spass mit Linux und systemd
Da bin ich wirklich gespannt, notfalls muss es eben Slackware sein.
Post by Stefan Kanthak
und UEFI und "secure boot".
Dir ist aber schon klar, wer UEFI federführend verbrochen hat? :o)
Stefan Kanthak
2015-02-04 17:47:12 UTC
Permalink
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Na ja, die zwei Versionen hatten den gleichen Namen...
... lagen aber in VERSCHIEDENEN Verzeichnissen.
Nein, die wurden vom originalen Installer in Abhängigkeit von der
Umgebung mit gleichem Namen im gleichen Verzeichnis aus
unterschiedlichen Quelle erzeugt.
Dir war bisher nicht bekannt/bewusst, das Programminstallationen
in Abhaengigkeit von der Umgebung verschiedene Dateien installieren
koennen?
AUTSCH!
Post by Edzard Egberts
Post by Stefan Kanthak
Und wovon bist Du jetzt abhaengig?
Von den VERALTETEN Header-Dateien des Win32-API, die MinGW mitbringt?
*Veraltet* ist saukomisch - Dir ist aber schon klar, dass vor kurzem
tausende von Leuten von einer *völlig veralteten* Windows-Version auf
eine *veraltete* Windows-Version umgestiegen sind?
Wer hat hierzugrupp neulich erst festgestellt, dass diese Header
nicht mal fuer den Funktionsumfang von XP geeignet sind?

Wieviele VOELLIG veraltet schreibst Du vor Deine Entwicklungsumgebung
jetzt?
Post by Edzard Egberts
Veraltet funktioniert wenigstens, guck' Dir mal die Marktanteile von
Win8 an!
Es geht aber nicht um Windows 8.
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Dann waren die MS-Development-Tools immer sauteuer
Ich habe mir vor 16 Jahren mal ein VC6 fuer DM 200,- gekauft.
Studentenversion?
Andere Seite.
Post by Edzard Egberts
Bin mir ziemlich sicher, dass kommerziell im vierstelligen Bereich
lag.
Die "dicken" Pakete.
Post by Edzard Egberts
Post by Stefan Kanthak
Ab 2003 gab's das kostenlose "Visual C++ Toolkit 2003"
Das war so ungefähr der Zeitpunkt, wo ich auf OpenSource umgestiegen
bin.
Doch SOOO frueh?
Ich habe GNU Zeux so etwa ab 1983 verwendet. Damals gab's auch noch
BITNET, EARN, CSnet, ...
Post by Edzard Egberts
Schreiend!
Post by Stefan Kanthak
Post by Edzard Egberts
Wenn man z.B. die Anzahl der Methoden von .NET und der FLTK vergleicht,
ist der Unterschied offensichtlich (mehrere Größenordnungen!).
Aha. Du kennst den Unterschied zwischen .NET und FLTK?
Klar, das eine ist ein gigantisches, völlig unbeherrschbares Framework,
das MS wahrscheinlich nie völlig fehlerfrei hin bekommt
Wieso sollten sie? Es ist inzwischen Open Source. Mach was draus!
Post by Edzard Egberts
und hunderte Megabyte zur Installation braucht, das andere ist klein,
überschaubar, leicht zu lernen und weitgehend fehlerfrei.
mit DEUTLICH geringerem Funktionsumfang fuer weitaus weniger Anwendungs-
faelle als .NET.
Post by Edzard Egberts
Mal davon abgesehn, dass .NET von Anfang an überflüssig war, weil
es Java schon gab und nicht nur auf Windows lief (Mono ignoriere
ich mal großzügigerweise).
Ist zwar richtig, aendert aber nichts am unpassenden Vergleich.

JFTR: ich mag .NET auch nicht, vor allem, weil Microsoft es wie ein
Drogendealer allen arglosen Windows-Nutzern aufdraengt, noch
dazu in mehreren Versionen.
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Stefan Kanthak
Frag die Verbrecher dieses Treibers, wieso sie ihn nicht signieren
lassen!
Das macht doch *niemand*, ist wahrscheinlich zu teuer und zu aufwändig.
VOELLIG AHNUNGSLOS!
Für mich ist es Standard, dass man unter Windows die Installation nicht
signierter Treiber bestätigen muss.
Zu dumm, dass jeder Administrator weiss, wie auch unsignierte Treiber
ohne diese Bestaetigungen installiert werden koennen.
Post by Edzard Egberts
Seit heute weiß ich auch, warum das so ist.
Wirklich?
Post by Edzard Egberts
Post by Stefan Kanthak
Such Dir einen Job, in dem Du keinen Flurschaden anrichtest.
Ach was, ich stehe da auf den Schultern von Riesen, schließlich kann ich
weder für Windows, noch für diesen Treiber etwas. Der größte
Volksschädling ist doch sowieso Microsoft, ich darf gar nicht daran
denken, was die XP-Abkündigung gekostet hat, selbst in dieser kleinen
Klitsche kamen deutlich über tausend Euro zusammen (Neues Windows und
neue Software mit aktuellen Lizenzen).
Schoene Milchmaedchenrechnung.
Wie auf- oder abwaertskompatibel sind denn "andere" Betruebssysteme?
Oder darauf laufende, "preiswerte" Kommerzware von Orrible,
Steinzeitlicher Anwender-Programmierung, ...?
Post by Edzard Egberts
Außerdem bin ich sowieso nur eingestellt worden, weil die Installation
von Matlab-Programmen so aufwändig ist und ich die in "C" umsetzen
sollte. :o)
Post by Stefan Kanthak
Beschwer Dich bei den Verbrechern des Treibers resp. dessen *.INF.
Die sind UNFAEHIG! VOELLIG UNFAEHIG!
Na ja, das wird sich wohl kaum ändern, wenn ich mich beschwere. Außerdem
hört sowieso niemand auf mich.
Nimm eine SS-20 und schick sie ihnen, ballistisch!
Post by Edzard Egberts
Post by Stefan Kanthak
AUTSCH!
Die armen Schweine, die dieses Zeux verwenden muessen, haben Schreib-
Rechte im Installationsverzeichnis und koennen/duerfen dort Dateinamen
aendern?
Klar, traditionell sind Windows-User doch immer noch als Admin
unterwegs.
Die Vollidioten bei Microsoft haben auch ihre Erbsuenden.-P
Nur: diese Administratoren tragen seit einiger Zeit eine
Narrenkappe, die ihnen das Aendern/Schreiben unter %SystemRoot%
und %ProgramFiles% nur nach Bestaetigung erlaubt.
Post by Edzard Egberts
Außerdem dachte ich eher an das installierte Verzeichnis.
Post by Stefan Kanthak
Post by Edzard Egberts
Als Unternehmer würde ich schon wieder völlig am Rad drehen...
Niemand zwingt Dich, Software fuer Windows zu frickeln!
Die frickele ich doch auch unter Linux zusammen (sonst würde ich mir
sofort einen anderen Job suchen) und die ist sowieso gerade nicht das
Problem, sondern die Windows- und Treiberinstallation. Normalerweise
kann man meine Software irgendwo hin kopieren und mit Doppelklick
ausführen, aber einen Treiber kann ich eben nicht statisch linken.
Linux mit seinem statisch gelinkten Kernel ist eben voellig veralteter
monolithischer Schrott.
Oder hast Du "initramfs" noch nicht entdeckt?
Post by Edzard Egberts
Post by Stefan Kanthak
2. viel Spass mit Linux und systemd
Da bin ich wirklich gespannt, notfalls muss es eben Slackware sein.
Post by Stefan Kanthak
und UEFI und "secure boot".
Dir ist aber schon klar, wer UEFI federführend verbrochen hat? :o)
Ich lass mir doch kein X fuer ein U vormachen! s/UEFI/EFI/
Du erinnerst Dich an ARC? "embrace & extend", oder umgekehrt.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Edzard Egberts
2015-02-05 10:47:58 UTC
Permalink
Post by Stefan Kanthak
Post by Edzard Egberts
Nein, die wurden vom originalen Installer in Abhängigkeit von der
Umgebung mit gleichem Namen im gleichen Verzeichnis aus
unterschiedlichen Quelle erzeugt.
Dir war bisher nicht bekannt/bewusst, das Programminstallationen
in Abhaengigkeit von der Umgebung verschiedene Dateien installieren
koennen?
Doch, in diesem Fall musste ich eben nur herausfinden, welche Dateien.
Post by Stefan Kanthak
Wer hat hierzugrupp neulich erst festgestellt, dass diese Header
nicht mal fuer den Funktionsumfang von XP geeignet sind?
Na ja, ich habe dann aber auch festgestellt, dass die alten Header
völlig ausreichen und die neuen Methoden nur Verwirrung stiften, weil es
zur Lösung *einer* Aufgabe jetzt *noch mehr* Möglichkeiten gibt, bei
denen man erst herausfinden muss, was, wann und wie funktioniert (oder
auch nicht).
Post by Stefan Kanthak
Wieviele VOELLIG veraltet schreibst Du vor Deine Entwicklungsumgebung
jetzt?
Also offiziell bin ich jetzt wieder auf dem neuesten Stand ("Win7
kompatibel"), das wird mir einfach so geglaubt! :o)
Post by Stefan Kanthak
Post by Edzard Egberts
Post by Stefan Kanthak
Ab 2003 gab's das kostenlose "Visual C++ Toolkit 2003"
Das war so ungefähr der Zeitpunkt, wo ich auf OpenSource umgestiegen
bin.
Doch SOOO frueh?
Ich habe GNU Zeux so etwa ab 1983 verwendet. Damals gab's auch noch
BITNET, EARN, CSnet, ...
Siehste, da habe ich noch mit MS-DOS gearbeitet und ab 1995 bin ich voll
auf die Windows-Schiene eingestiegen und war zuerst voll überzeugt. Dann
musste ich dummerweise Software schreiben, die garantiert nie abstürzt
(weil da eine Maschine dran hing), war für alle Fehler verantwortlich
und musste feststellen, dass die meisten Probleme gar nicht von mir
verursacht wurden. War immer ganz toll, wenn es wirklich mein Fehler
war, den konnte ich wenigstens korrigieren. :o/
Post by Stefan Kanthak
Post by Edzard Egberts
Klar, das eine ist ein gigantisches, völlig unbeherrschbares Framework,
das MS wahrscheinlich nie völlig fehlerfrei hin bekommt
Wieso sollten sie? Es ist inzwischen Open Source. Mach was draus!
Ach, so einen Code spare ich mir lieber. Microsoft hat es ja über 13
Jahre nicht geschafft, WinXP sicher zu machen, da tue ich mir so eine
Baustelle erst recht nicht an.
Post by Stefan Kanthak
Post by Edzard Egberts
Für mich ist es Standard, dass man unter Windows die Installation nicht
signierter Treiber bestätigen muss.
Zu dumm, dass jeder Administrator weiss, wie auch unsignierte Treiber
ohne diese Bestaetigungen installiert werden koennen.
Beim Booten F8 drücken, mit bcdedit Einstellungen ändern, oder beim
Booten in irgend so einem Einstellungs-desk die Prüfung komplett
abschalten. Wenn ich vom User so etwas erwarten dürfte, könnte ich mir
einen Installer sparen - Administrator braucht eben etwas Ausbildung...
Post by Stefan Kanthak
Post by Edzard Egberts
Klar, traditionell sind Windows-User doch immer noch als Admin
unterwegs.
Die Vollidioten bei Microsoft haben auch ihre Erbsuenden.-P
Hehe, sehe ich genau so, das haben die von Anfang an vergurkt, von wegen
der User soll alles selber machen oder ggf. seinen Netzwerkadmin fragen.
Und Leute, die wirklich Ahnung haben, fangen mit ihrer Zeit lieber etwas
anderes an, weil Windows frickeln kann ja jeder und niemand will dafür
bezahlen. Das hat Apple deutlich besser gemacht.
Post by Stefan Kanthak
Nur: diese Administratoren tragen seit einiger Zeit eine
Narrenkappe, die ihnen das Aendern/Schreiben unter %SystemRoot%
und %ProgramFiles% nur nach Bestaetigung erlaubt.
Als ob das einen User vom Klicken abhält. Der Klassiker waren doch die
ausführbaren Anhänge von E-Mails...
Stefan Kanthak
2015-02-05 14:37:16 UTC
Permalink
[...]
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Für mich ist es Standard, dass man unter Windows die Installation nicht
signierter Treiber bestätigen muss.
Zu dumm, dass jeder Administrator weiss, wie auch unsignierte Treiber
ohne diese Bestaetigungen installiert werden koennen.
Beim Booten F8 drücken, mit bcdedit Einstellungen ändern, oder beim
Booten in irgend so einem Einstellungs-desk die Prüfung komplett
abschalten. Wenn ich vom User so etwas erwarten dürfte, könnte ich mir
einen Installer sparen - Administrator braucht eben etwas Ausbildung...
Otto Normalverbraucher liest diesen einen von 1001 hoechst geheimen
Tricks in der PC-BLOED oder PC-Proll oder im sog. Netz und probiert
ihn latuernich aus.
Post by Edzard Egberts
Post by Stefan Kanthak
Post by Edzard Egberts
Klar, traditionell sind Windows-User doch immer noch als Admin
unterwegs.
Die Vollidioten bei Microsoft haben auch ihre Erbsuenden.-P
Hehe, sehe ich genau so, das haben die von Anfang an vergurkt, von wegen
der User soll alles selber machen oder ggf. seinen Netzwerkadmin fragen.
Und Leute, die wirklich Ahnung haben, fangen mit ihrer Zeit lieber etwas
anderes an, weil Windows frickeln kann ja jeder und niemand will dafür
bezahlen. Das hat Apple deutlich besser gemacht.
Post by Stefan Kanthak
Nur: diese Administratoren tragen seit einiger Zeit eine
Narrenkappe, die ihnen das Aendern/Schreiben unter %SystemRoot%
und %ProgramFiles% nur nach Bestaetigung erlaubt.
Als ob das einen User vom Klicken abhält. Der Klassiker waren doch die
ausführbaren Anhänge von E-Mails...
Eine weitere Erbsuende.

JFTR: NTFS kennt ein Recht "Dateien ausfuehren".
Das muss in Benutzerprofilen nicht gesetzt sein.

Alternativ: Software Restriction Policies alias SAFER.

Kurz: Safer Hex.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Loading...