Steht nicht dabei, ist aber gemeint:
Alles unterhalb Ultimate und alles nach Vista ist von dieser Herzigkeit ausgenommen.
Genauso das neue Kartell nach SCO mit Novell zur Abhaltung von Open Source Linuxen vom Teilen von proprietären Treibern und Konzepten. Alles gegen die EU Kommsissionsentscheidungen, wo nachzulesen ist, daß die APIs, Beispielcode und Quellcode zugänglich gemacht zu werden hat, sofern notwendig, um andere nicht auszuschliessen.
Ich möchte nur ein Beispiel bringen:
Beim Beenden eines Threads, der mit CreateThread() erzeugt wurde, bleiben 70-80 Bytes am Stack stehen und das führt somit zu einem Speicherleck.
Dagegen beginthread(), wo alles proper funktioniert, aber leider, leider, leider kann man signal() nicht verwenden.
Nur unter Visual C++ und unter Verwendung von beginthreadex() werden Signale, die an den Thread geschickt wurden, korrekt abgehandelt.
Wo bleibt der Quellcode von beginthreadex ?
Visual C++ soll wie Office xy zum Standard erhoben werden. Wie gehabt: Nicht zugänglich machen von Informationen, APIs und den Quellcode soweit notwendig nicht dokumentieren, nicht das Teilen von Code, Konzepten usw. zulassen.
Beispiel:
Zitat:
# CreateThread() is called with three NULL parameters: CreateThread(NULL,NULL,(LPTHREAD_START_ROUTINE)Thr eadFunc,this,NULL,&Dummy).
# You need to link with the multi-threaded version of the CRT library. Go to Project Settings, C/C++ tab, Use run-time library must be Multithreaded or Multithreaded DLL for your release builds.
# There is a warning about the memory leaks when you use CRT functions in your thread functions started by calling the CreateThread function, and you are usually warned of using _beginthreadex instead. My code has been coded to call CreateThread, and it has to be that way. However, there is still a workaround to cope with the memory leak issues even if you do it.
You may wonder why your Win32-based applications seemed to work over the years even though you've been calling CreateThread instead of _beginthreadex. When a thread calls a CRT function that requires the tiddata structure (which is usually allocated and initialized by _beginthreadex), here is what happens. First, the CRT function attempts to get the address of the thread's data block (by calling TlsGetValue). Second, if NULL is returned as the address of the tiddata block, then the calling thread doesn't have a tiddata block associated with it. At this point, the CRT function allocates and initializes a tiddata block for the calling thread right on the spot. The block is then associated with the thread (via TlsSetValue), and this block will stay with the thread for as long as the thread continues to run. Third, the CRT function can now use the thread's tiddata block, and so can any CRT function that is called in the future. This, of course, is fantastic because your thread runs without a hitch (almost). Well, actually there are a few problems here. If the thread uses the CRT's signal function, the entire process will terminate because the structured exception handling frame has not been prepared. Also, if the thread terminates without calling _endthreadex, the data block cannot be destroyed and a memory leak occurs. So, if you would call _endthreadex for a thread created with CreateThread, you should be OK.
|