Hallo,
Die von dir verlinkte Beschreibung von MS ist unvollständig: Anders als dort angegeben suchen diese Funktionen (zumindest bis Windows XP, für Vista oder 7 keine Garantie) die Datei zuerst im Verzeichnis der Applikation (also das Verzeichnis, in dem die EXE-Datei liegt), dann im Windows-Verzeichnis.
Hmmm, genau das hatte ich auch im Kopf, aber das ist das Suchverhalten für DLLs (LoadLibrary()), nicht für INIs.
ich dachte für beides ... aber du hast mich verunsichert. Ich habe jetzt tatsächlich mal in die Quellcodes meiner Standardmodule gesehen, die ich seit Jahren quasi unverändert benutze: Ich frage über GetModuleFileName() den Namen der EXE-Datei ab, schneide die drei Zeichen am Schluss ab und ergänze "ini" oder "cfg".
Sorry: Mein Irrtum lag darin, dass ich überzeugt war, GetModuleFileName() gäbe mir nur den Namen - tatsächlich liefert mir das aber den kompletten Pfad. Dann ist logisch, dass ich auch die INI-Datei im Programmverzeichnis finde.
Oder halt exakt da, wo's der Programmierer vorgibt, wenn ein Pfad angegeben wird.
Ja, genau.
So wie bei mir - nur dass mir das nicht mehr bewusst war.
Das sysinternals-Tool FileMon kann zwar Zugriffe beliebiger Prozesse auf das Filesystem überwachen und protokollieren, aber AFAIK nicht eingreifen.
Richtig. Und laut Regmon fragt weder Entwicklungsumgebung noch Runtime die Registry ab, wo die INI-Datei denn liegen soll. *grummel*
Das wär ja dann auch zu einfach gewesen.
Was waren das noch für Zeiten, als man einfach den DOS-Interrupt 21h abgefangen und die Funktionsnummern und Parameter einfach abgefragt und umgebogen hat ...
Ja, und sich dann irgendwann gewundert hat, warum die Kiste abstürzt, nur weil der blöde Interupt irgendwo ins mittlerweile überschriebene Nirvana zeigt ... ;-)
Das auch gelegentlich. Meist hat es aber ganz gut funktioniert, weil die Systeme und Zusammenhänge noch überschaubar waren.
Ciao,
Martin
Verliebt: Er spricht, sie lauscht.
Verlobt: Sie spricht, er lauscht.
Verheiratet: Beide sprechen, und die Nachbarn lauschen.