warten bis anwendung gestartet wird...

[brechi]

@SirThornberry Process32First ist immer der SystemProcess von daher ist es total bob ob man ne repeat oder while schleife nimmt, schöner ist aber die repeat schleife.

[Olli]

Zitat:

Zitat von brechi

@SirThornberry Process32First ist immer der SystemProcess von daher ist es total bob ob man ne repeat oder while schleife nimmt, schöner ist aber die repeat schleife.

Dies ist eine unzulässige Annahme, genauso wie die Annahme, daß ein Integer 32bit breit sei, oder ein Byte auf jedem Compiler 8 Bit habe. Vergiß es also lieber wieder ;)

[brechi]

das ist keine unzulässige annahme, genausowenig wie Module32First immer das exe-progamm selbes (exename, exehandle etc) liefert

und was das mit dem byte und integer zu tun hat weiß ich auch nicht, nen byte hat 8 bits (0..255) sonst wäres kein byte, wie es intern gehandelt wird, d.h. trotzdem als integer etc. muss dich ja nicht interessieren, wenn die API nunmal so funktioniert kann man das auch benutzen.

Edit:
du meinst bestimmt es wäre keine Spezifikation da MS dies nie so gesagt hat. eine Annahme ist das so lange bis es mir einer widerlegt hat

[Olli]

Zitat:

Zitat von brechi

das ist keine unzulässige annahme, genausowenig wie Module32First immer das exe-progamm selbes (exename, exehandle etc) liefert

Da du keinen Einfluß darauf hast, ist diese Annahme unzulässig!

Die Größe eines Bytes läßt sich mit sizeof() ermitteln. Die Annahme, daß der Rückgabewert bei einem Byte 1 ist, ist unzulässig! Hat etwas mit portablem Code zu tun.

Zitat:

Zitat von brechi

wenn die API nunmal so funktioniert kann man das auch benutzen.

Das tut sie aktuell, und du kannst sie durchaus selber so benutzen, allerdings sollte man nicht in einem Forum, wo sich Programmierer und nicht "Coderz" unterhalten solche Tips geben, die auch mal schnell in die Hose gehen können - oder zumindest über die Nebenwirkungen aufklären. In die Hose gehen kann das nämlich genaugenommen mit jedem einzelnen neuen Patch der aus Redmond kommt.

Du kannst dagegen "argumentieren" wie du willst. Da die von dir genutzte Funktionalität nicht dokumentiert ist, kann sie sich jederzeit ändern - genau wie bspw. die Native APIs in einem gewissen Rahmen sich ändern können. Entweder man weist explizit darauf hin und nimmt diese Möglichkeit in Kauf, oder man eben nicht. Aber da du nicht darauf hinweist, überläßt du nicht etwa dem Fragesteller die Entscheidung darüber, sondern enthältst ihm eine vitale Information vor.

Zitat:

Zitat von brechi

du meinst bestimmt es wäre keine Spezifikation da MS dies nie so gesagt hat. eine Annahme ist das so lange bis es mir einer widerlegt hat

Dazu brauche ich nur einen Toolhelp-API-Ersatz für NT4 einführen, bei dem dies nicht der Fall ist. Damit ist die Annahme bereits widerlegt. Wie du siehst, ist nicht eine Zeile Code von MS nötig um deine Bedingung zu erfüllen.

[SirThornberry]

@brechi: ein Integer hat zur Zeit bei den meisten 32 Bit, früher war er mal 16 Bit und in naher Zukunft ist er 64 bit.
Ich würde auch nicht davon ausgehen das der erste Prozess immer der Systemprozess ist solange es nicht explizit im msdn steht.
Die Annahme ist ähnlich wie die das FindFist, FindNext die Dateinamen in alphabeticher Reihenfolge zurück gibt (ist nur bei NTFS laut msdn so), es ist eben abhängig von den äußeren Umständen. Und vielleicht ist bei der nächsten Windowsversion der erste Prozess nicht mehr der Systemprozess - und dann müsste man sein Programm umbauen. Also am besten immer gleich richtig machen so wie es im msdn steht.

[brechi]

1) du meintest ein byte besteht nicht immer aus 8 bit, das tu es wohl, wie es intern gespeichert ist ist es egal
wenn ich also nen byte benutze kann ich ausgehen, dass ich zahlen von 0 bis 255 darstellen kann. das nen sizeof nicht 1 zurückgeben muss hat doch nichts damit zu tun das das byte trotzdem aus 8 bits besteht.

also könntest höchstens sagen nen byte hat 8 setzbare bits muss aber nicht 8 bit groß sein, desweiteren kann man wenn schon bei sizeof nicht davon ausgehen das es bei einem byte halt imemr 1 liefert. das da eventl was falsches rauskommt liegt halt an dem sizeof und nicht etwa an dem aufbau von nem byte

2) anders ist es bei nem integer, das muss nicht immer 32 bit groß sein, und wie man sieht ist es nunmal so das für 64 bit eben die programme umgeschireben werden müssen, das liegt aber nicht daran das der programmierer davon ausgeht, dass es halt immer 32 bit hat.
davon kann man und jeder programmierer muss sogar davon ausgehen, schließlich programmieren wir hier immer noch mit delphi für nen x86 und windows. die programme werden halt nicht auf nem 64bit system laufen, deshalb gibt es halt da noch die 32bit emulierung - oder wie auch immer es MS macht.

als beispiel hättest vielleicht char nehmen könne was in delphi 8bit und in java 16bit groß ist
aber auch hier darf ich in meinem delphi programm selber davon ausgehen, dass es nunmal 8bit groß ist.

das man durhc irgendwleche hacks den verlauf immer ändern kann ist auch klar. aber es gibt halt auch annahmen wie z.b. GetModuleHandle('kernel32.dll') ist immer gültig, die deiner auffassung ja von MS nie so gesagt werden, aber meiner meinung nach immer stimmen. sollten sie nicht stimmen, muss halt jemand etwas gehackt haben (dll aus der <nameeintragen> tabelle gelöscht haben etc.)

@FindFist, FindNext die Dateinamen in alphabeticher Reihenfolge: MS sagt ja selbst das es nur für NTFS gilt, dann kann man sich auch nicht drauf verlassen :)
und es stimmt ja auch bei fat nicht, aber du kanns mir auch kein windows/irgendwleche einstelleungen ala (fat32/ntfs) sagen wo meine 3 behauptungen/annahmen (module32firs,process32first,getmodulehandle('kern el32.dll')) nicht stimmen

desweiteren unterstütz ich das mit der while schleife auch nicht, und bin auch sehr pingelig wenns um sowas geht. aber grundsätzlich wäre es egal - wenn die repeat scleife acuh schöner/besser/sicherer ist.

aber manchmal bruacht man halt doch annahmen wie z.b. wie kommt man an des modulhandle ohne GetModuleHandle etc. und wenn man des dann weiß ist es besser, wenn mans auch für andere benutzungen nicht verwenden sollte

[SirThornberry]

@brechi: Du hast schon recht, olli und ich (zumindest ich) wollten einfach damit sagen das man nicht immer von etwas ausgehen kann nur weil nicht das gegenteil irgendwo geschrieben ist.

Es ist doch zum Beispiel bedeutend einfacher ein Projekt von Delphi32 zu nehmen und einfach mit einem 64Bit Delphicompiler zu kompilieren als das Projekt dann neu zu schreiben.

Wenn solche Annahmen sind as zum Beispiel der erste Prozess immer der Systemprozess ist sollte man explizit dazu schreiben das dies nur eine Annahme ist die unter dem aktuellen Betriebssystem zutrifft. Ansonsten könnte das ein Unwissender so aufgreifen und wundert sich später das etwas nicht funktioniert weil der davon ausgeht das deine Annahme (die nicht als Annahme markiert war) eine Festlegung war.

[Olli]

Zitat:

Zitat von brechi

1) du meintest ein byte besteht nicht immer aus 8 bit, das tu es wohl, wie es intern gespeichert ist ist es egal
wenn ich also nen byte benutze kann ich ausgehen, dass ich zahlen von 0 bis 255 darstellen kann. das nen sizeof nicht 1 zurückgeben muss hat doch nichts damit zu tun das das byte trotzdem aus 8 bits besteht.

Wenn du es so sagen willst, dann müßte es heißen: Mindestens 8 Bit.

Zitat:

Zitat von brechi

das man durhc irgendwleche hacks den verlauf immer ändern kann ist auch klar. aber es gibt halt auch annahmen wie z.b. GetModuleHandle('kernel32.dll') ist immer gültig, die deiner auffassung ja von MS nie so gesagt werden, aber meiner meinung nach immer stimmen. sollten sie nicht stimmen, muss halt jemand etwas gehackt haben (dll aus der <nameeintragen> tabelle gelöscht haben etc.)

Im Falle von Kernel32.dll wird es vermutlich auch auf zukünftigen Systemen stimmen (müssen), aber man sollte sich dennoch nicht darauf verlassen, sondern den Rückgabewert auch hier testen.

Zitat:

Zitat von brechi

aber manchmal bruacht man halt doch annahmen wie z.b. wie kommt man an des modulhandle ohne GetModuleHandle etc. und wenn man des dann weiß ist es besser, wenn mans auch für andere benutzungen nicht verwenden sollte

Wohl wahr. Daß ich es weißt, sollte dir klar sein. Solche Annahmen sollten aber in einem engen Rahmen eingesetzt werden und wenn möglich sollte (zB in so einem Forum wie hier) auf die Nebenwirkungen hingewiesen werden.

[brechi]

ich bin ja auch eigentlich deiner meinung. imho läuft das auf allen BS, aber man sollte halt nichst benutzen was in der zukunft geändert sein könnte.