romeon schrieb:
das liegt aber nur zum Teil an den "idiotischen" Programmierern, denn es muss ja vormals auch "Idioten" gegeben haben, die das exakt so vorgesehen hatten. Und das waren nun mal die von Microsoft. Hätten sie mal lieber diesen Schritt/Schnitt vor Win7 oder noch besser vor XP gemacht, denn Win8 hat es auch ohne diese "absichtlichen" Inkompatibilitäten schon weiß gar nicht leicht ...
Was für absichtliche Inkompatibilitäten? Wer hat das so vorgesehen? Wieso muss es "vormals" so etwas gegeben haben? Ist ja nicht so, dass nicht jeder "Entwickler" einfach mal so
irgendwas hinzaubern kann. Schön wie du aber versuchst es MS anzulasten, weil sie eine Möglichkeit
im Fall der Fälle anbieten. Deswegen ist es nicht der richtige Weg.
Wer ist aber eigentlich dran Schuld, dass "Entwickler" "C:\Windows\system32" im Pfad angeben? MS natürlich, weil die den Pfad einfach nicht im Nachhinein ersetzen und somit schöne Seiteneffekte und nicht vorhergesehen Bugs mit ins Programm durch den Compiler schleusen. Natürlich...
Es gibt nun mal nicht umsonst Umgebungsvariablen, die auch genutzt werden sollen. Wenn sich Hanswurst eben denkt "brauch ich nicht", ist das nicht die Schuld vom OS-Hersteller. %userprofile%, %systemroot%, %appdata%, %temp%, %programfiles% etc. gibt es nicht, weil MS absolute Pfade liebt. Und selbst wenn es MS so machen sollte, gibt es immer noch keinen Grund, warum ein anderer Entwickler es nicht richtig machen sollte. Dilettanten-Entwickler gibts leider viel zu oft und wenn man sich so manchen Spaghetti-Code ansieht, wo selbst in C++ noch (sinnlose) gotos [1] verwendet werden, muss man sich nicht wundern. Wenn jeder auch nur die API richtig verwenden würde, gäbe es gar nicht solche Inkompatibilitäten.
Wunderbar auch an versauter Verschlüsselung einiger Entwickler zu sehen, da sie zwangsweise meinen, die Verschlüsselung selbst implementieren zu müssen, anstatt bspw. auf OpenSSL zu setzen und so vorhandenes und bewährtes zu nutzen.
Ein sehr schönes Beispiel ist auch
LoadLibrary().
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175%28v=vs.85%29.aspx schrieb:
If lpFileName does not include a path and there is more than one loaded module with the same base name and extension, the function returns a handle to the module that was loaded first.
Manche "Entwickler" meinen hier aber eine eigene DLL mitzuliefern und einzubinden müssen. Das resultiert dann in der bekannten DLL-Hell, was spätestens seit Vista mit dem WinSxS-Verzeichnis der Vergangenheit angehören sollte. "Entwickler" laden DLLs dann eben per "./abc.dll". Schon krachts und abc.dll wird immer aus dem Arbeitsverzeichnis geöffnet werden. Würde man stattdessen "abc.dll" angeben, würde Windows sich darum
mit bestimmtem System kümmern, die richtige DLL mit richtiger Version herauszusuchen.
Wo war die Schuld nochmal? Nicht beim OS-Hersteller... Entwickler halten sich einfach nicht an Vorgaben, sei es aus Faulheit (nicht lesen wollen), Sturheit (ach das passt schon so wie es ist) oder Überheblichkeit (ich kann das genauso gut bzw. besser). Das passende Beispiel haben wir in dieser News!
Der nächste Graus, ist das Zusammenstellen von Pfaden. Da wird in PHP bspw. eben
require 'abc/'.$def.'/ghi/jkl'.$mno.'.php' gemacht. Es wäre ja zu einfach eine Funktion zu schreiben, die mir einen sauberen Pfad zurückgibt, welche ich einfach mittels
BuildPath( 'abc', $def, 'ghi/jkl', $mno.'.php' ); aufrufen könnte und zudem bspw. noch OS unabhängig laufen könnte (Windows \, Linux/Mac / als Path Delimiter).
Anderes Thema...
edit:
[1] Nicht dass sie sinnlos sind, aber im dortigen Code eben sinnloserweise verwendet werden.