"Veraltete" Funktionen LoadBitmap(), LoadCursor() und LoadIcon()
-
hi
das thema sicherheit möchte ich nicht anschneiden .. doch eines ist klar, sie sind langsamer..
lowbyte
-
berniebutt schrieb:
Wenn etwas zufriedstellend läuft, braucht man es nicht durch neuere Konzepte ersetzen. Es sei denn es bringt Vorteile, die ich aber nicht sehe. :p
Bei Deprecated Sachen bin ich da vorsichtig. Bisher hat man immer noch Abwärtskompatibel entwickelt. Aber nicht jeder Funktionsaufruf ist in jeder Windowsfunktion komplett gleich.
Und gerade wenn von Offizieller Stelle beschrieben ist, das eine Funktion deprecated ist, und mir schon die Alternative bekannt ist, werde ich sicherlich nicht die deprecated Funktion verwenden, wenn ich weiß das die neue Version zumindest genau das gleiche tut. Es könnte ja wirklich sein, dass MS irgendwann mal sagt das die alten Funktionen nun gar nicht mehr unterstützt werden (Sind ja schließlich nun schon als Deprecated markiert).
Ob man deswegen gleich alle laufenden System Updaten sollte, steht auf einen anderen Blatt.
-
Fedaykin schrieb:
... Bisher hat man immer noch Abwärtskompatibel entwickelt. ...
Ich denke, das wird auch hier noch sehr lange der Fall sein oder nie gekippt. Also, keine Panik und kein Zwang zum sofortigen Umschreiben bestehender Programme! WinExec aus alten 16-bit-Zeiten läuft auch noch tadellos.
-
[quote="berniebutt"]
Fedaykin schrieb:
WinExec aus alten 16-bit-Zeiten läuft auch noch tadellos.
Auch noch unter den 64-Bit Systemen?
-
lowbyte_ schrieb:
hi
das thema sicherheit möchte ich nicht anschneiden .. doch eines ist klar, sie sind langsamer..
lowbyte
Hi, lowbyte_, langsame Geschwindigkeit ist für mich kein Hindernis.
Erhöhte Sicherheit dagegen interessiert mich schon.Deshalb möchte ich gerne wissen wo Du das mit der Sicherheit gelesen hast.
(Ich interpretiere "Sicherheit" als "erhöhte Sicherheit", falls Du das so meinst)Martin
-
1. Ist da nichts schneller
2. Ist da nichts sicherer/unsichererSowohl LoadIcon als auch LoadImage Sind Wrapper um die selbe interne Funktion LoadIcoCur@24...
Einfach mal im Debugger reingehen und ansehen...
-
Könnt mal bitte jemand gucken, ob WinExec unter 64-Bit noch verfügbar ist? Nur aus Interesse. Weil offiziell unterstützt 64.Bit ja keine 16-Bit Anwendungen mehr.
-
_Luckie schrieb:
Könnt mal bitte jemand gucken, ob WinExec unter 64-Bit noch verfügbar ist? Nur aus Interesse. Weil offiziell unterstützt 64.Bit ja keine 16-Bit Anwendungen mehr.
Und was hat das eine mit dem anderen zu tun?
Warum verwendest Du WinExec wenn man auch ShellExecute benutzen kann?
Was sagt die MSDN? http://msdn.microsoft.com/en-us/library/ms687393(VS.85).aspx
Siehst Du dort eine Einschränkung, dass die aktuelle Kernel32.lib diese nicht enthalten soll?
-
Ich verwende WinExec nicht. Microsoft hat die Funktion nur schon länger als veraltet deklariert und ich wollte jetzt wissen, ob sie unter 64-Bit endlich verschwunden ist, bzw. ob Microsoft seine Warnung endlich war gemacht hat.
-
_Luckie schrieb:
Ich verwende WinExec nicht. Microsoft hat die Funktion nur schon länger als veraltet deklariert und ich wollte jetzt wissen, ob sie unter 64-Bit endlich verschwunden ist, bzw. ob Microsoft seine Warnung endlich war gemacht hat.
In VS-2010 mit aktuellem SDK ist diese Funktion deprecated:
__drv_preferredFunction("CreateProcess","Deprecated. See MSDN for details") WINBASEAPI UINT WINAPI WinExec( __in LPCSTR lpCmdLine, __in UINT uCmdShow );Wenn Du sie verwendest bekommst Du eine Compiler-Warnung. D.h. nicht, dass Sie nicht mehr vorhanden wäre.
-
Hi
@Martin Richter
Sorry für die falschen Infos.
Das hätte ich machen können ja, doch habe mir die Funktion LoadImage() bis jetzt nie genau angeschaut, daher meine falschen Posts, zu behaupten das die Funktion schneller und sicherer wäre. Kommt alles daher weil ich weis, oder dass auch belegen könnte das die Funktion LoadBitmap() seine Maken hat !! Daher bin ich automtisch davon ausgegeangen das die Funktion LoadImage() das jetz besser Handel't.Näher möchte ich das Problem dieser Funktion nicht schildern, da wir hier nicht auf einem 0ra0ker Board sind. Aber kann dir gerne Persönlich davon berichten.
So wie es scheint hat sich nichts geändert. Schade Billi (ir)
lowbyte
-
lowbyte_ schrieb:
Kommt alles daher weil ich weis, oder dass auch belegen könnte das die Funktion LoadBitmap() seine Maken hat !!
Ja, das stimmt so richtig. LoadImage() kann nun mal viel mehr Sonderfälle abarbeiten.
Mittlerweile weiß ich ein wenig mehr über diesen Sachverhalt:
Beispielsweise kann LoadImage() besser mit allen Variationen von Farbpaletten korrekt umgehen, während LoadBitmap() nur bei bestimmten Farbtiefen fehlerfrei arbeitet.Analog gilt auch für LoadIcon(): Dieser kommt z.B. nicht mit allen verschiedenen Icon-Größen zurecht.
Insofern sollte man schon die Empfehlung von der MSDN ernst nehmen, zumindestens für Neuentwicklungen nur noch LoadImage() zu verwenden.
Denn eine kleine Änderung (z.B. geändertes Bitmap- oder Icon-Objekt) kann bei einem Nutzer mit einer anders eingestellten Bildschirm-Farbtiefe evtl. zu unschönen Effekten führen.HTH,
Martin
-
Hi
Geschwiegen von den Sicherheitslücken !
Aber wie gesagt das gehört nicht in dieses Forum.lowbyte
-
lowbyte_ schrieb:
Hi
Geschwiegen von den Sicherheitslücken !
Aber wie gesagt das gehört nicht in dieses Forum.lowbyte
Weswegen du es ja auch mehrfach hier erwähnt hast. Vollkommen logisch!
-
hi
??wollte nur darauf hinweisen !
da die sicherheit in einem programm vorgeht!
was genau da jetz unsicher sein soll, möchte ich hier nicht erklären, da dies zum einen für die admins ein debakel wäre, und zum anderen diese lecks nocht öffentlich bekannt sind.
die die zbsp. stuxnet programmiert haben, können euch ein lied davon singen
lowbyte
-
hi
obwohl die lücken die stuxnet ausnutzt nichts mit dirsen hier zu tun hat.
hiermit ist für mich dieser thread geschlossen.lowbyte
-
hast du es wenigstens schon an MS reportet?
-
Hi
no comment !
lowbyte
