"Veraltete" Funktionen LoadBitmap(), LoadCursor() und LoadIcon()



  • Hi folks,

    die meisten von Euch kennen sicher die API-Funktion LoadBitmap() http://msdn.microsoft.com/en-us/library/dd145033(VS.85).aspx.

    Was mich da wundert, dort ist zu lesen: LoadBitmap() has been superseded by the LoadImage() function.
    Das gleiche lese ich auch bei LoadCursor() http://msdn.microsoft.com/en-us/library/ms648391(v=VS.85).aspx
    und bei LoadIcon() http://msdn.microsoft.com/en-us/library/ms648072(v=VS.85).aspx.

    In meinen Applikationen habe ich natürlich LoadBitmap(), LoadCursor() und LoadIcon() verwendet, schon seit meinem Selbststudium in Charles Petzolds legendärem Buch...

    Nun meine Frage:
    Ist es empfehlenswert, diese drei Funktionen heute durch LoadImage() zu ersetzen?
    Ich denke mal ja, wenn Microsoft dies ausdrücklich in der MSDN empfiehlt.
    Und warum? Ja, warum eigentlich? Sie funktionieren heute noch unter Windows 7.
    Aber andererseits, auch heute noch lese ich in den Samples und in den Foreneinträgen immer noch die Verwendung von diesen drei "deprecated" Funktionen... 😮

    Martin



  • 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



  • hi

    sicherheit !

    lowbyte



  • @berniebutt:
    Ja, genau so sehe ich das auch. Nicht umsonst gibt es den Spruch "Never touch a running system" 🙄 .
    Jedenfalls, solange ich nichts weiß, warum LoadImage() besser sein soll...

    @lowbyte_:
    Warum soll LoadImage() sicherer sein als diese drei erwähnten Funktionen?

    Ich habe soeben einige Applikationen sicherer gemacht was "DLL preload attack" betrifft.
    Da würde es ja gut dazu passen in dem Workaround auch gleich die Loadxxx() Funktionen sicherer zu machen.
    Meine ersten Online-Suche mit Google und bing (Suchbegriffe "LoadBitmap Sicherheit" bzw. "security") haben mir da nicht weitergeholfen.
    Und ohne Quellennachweis ändere ich nun mal nichts überstürzt...

    Hast Du da einen Quellennachweis für mich?

    Martin



  • 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


  • Mod

    1. Ist da nichts schneller
    2. Ist da nichts sicherer/unsicherer

    Sowohl 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.


  • Mod

    _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.


  • Mod

    _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


Anmelden zum Antworten