Program Files(x86) überhaupt noch sinngemäß

[jfheins]

Zitat von EWeiss:

Bsp.
Ich starte die IDE VB6 aus Program Files(x86)\Microsoft Visual Studio\VB98 mit meinem VB6 Projekt.
Die erste Meldung VB6 kann nicht auf die Registry zu greifen.
Gut und schön, oder auch nicht.

Ich weiß nicht, ob VB6 hier das beste Beispiel ist. Aber der grundsätzliche Gedanke ist ja: Binaries nach C:/Programme und Daten nach Dokumente/AppData/ProgramData oder so. IN einer perfekten Welt würden sich die Programme dann gut starten lassen (C:/Programme wird ja vor Änderungen geschützt) und diese Programme können dann Daten (Word-Dokumente, Musikdateien/ Zeug) in anderen Ordnern lesen/schreiben.

Eine IDE ist hier nicht anders: Die IDE selbst sollte unter C:/Programme sein und die Nutzerdaten woanders. Dabei ist absolut nebensächlich, dass diese Nutzerdaten wieder kompilierte Programme sind.
Visual Studio legt die Daten unter "C:\Users\xxx\Documents\Visual Studio 2017\Projects" ab. Dort kann man auch ohne Adminrechte schreiben und schnell mal ne Änderung testen.

Leider kann man dort auch im gleichen Verzeichnis wie die Anwendung Daten speichern, was die Entwickler verführt, dies zu tun. Aber später (wenn ein Release veröffentlicht wird) sollte die Software beim Endnutzer ja wieder in C:/Programme landen. (oder dem Äquivalent "C:/Programme (x86)")

Kurzum: Bei alten Delphis kann man glaube ich den Standard-Projekte Ordner selbst einstellen, sobald man den nicht mehr unter C:/Programme hat, sollte es auch ohne Adminrechte gehen. Ich vermute bei VB6 ähnliches.

Zitat:

Anwendung die Vollzugriff auf Dateien oder der Registry benötigen

Oha, "Vollzugriff" gleich o.O ISt das dann ein Low-Level Datenrettungstool? Für einen Musikplayer sollte doch ein einfacher Zugriff reichen

[jaenicke]

Zitat von EWeiss:

Welche Funktion hat dieser Ordner noch? Bzw. was für eine Berechtigung noch zu existieren wenn am ende keine Anwendung die Vollzugriff auf Dateien oder der Registry benötigen nicht mehr richtig funktionieren.

Weil es nur verhältnismäßig wenige Programme gibt, die einen solchen Zugriff benötigen. Das sind in der Regel Systemtools wie Partitionierungstools usw. und die bekommen dann ja ohnehin Adminrechte.
Aber bevor man diese gibt, sollte man sich genau überlegen, ob die Software diese wirklich für den gedachten Anwendungsfall benötigt.

Ich habe nun nicht gerade wenig Software installiert. Aber die funktionieren alle problemlos mit einer Installation unter Program Files inklusive meiner eigenen. Es gibt zwar Software, die sich auch nicht unter Program Files installiert, aber das sind meistens Programme, die sich selbst aktualisieren wollen wie Google Chrome. Das ist zwar der falsche Weg, aber auch die funktionieren unter Program Files normal, brauchen dann aber einen Dienst zur Aktualisierung.

Ältere Software läuft bei mir in einer VM mit dem dazu passenden Betriebssystem. Wobei das aktuell im Grunde nur noch Delphi 1 bis XE, Windows 3.x usw. zu Testzwecken ist. Produktiv nutze ich keine ältere Software mehr. Ältere Software oder mit älteren Entwicklungsumgebungen erstellte Software haben mit aktuellen Systemen eben durchaus Probleme. Und das gilt eben auch für VB6.

Es würde aber ja auch niemand auf die Idee kommen die Scheinwerfer aus einem Trabbi in einen 5er BMW einzubauen, also warum wird so viel alte Software statt in einer VM versucht unter neuen Betriebssystemen einzusetzen...

VB6 sollte eben besser in einer VM mit XP laufen und damit erstellte Software auch nicht unter Vista oder höher eingesetzt werden.

[Bernhard Geyer]

Program Files(x86) überhaupt noch sinngemäß - Ja, sehr.
Programm die darunter nicht laufen fliegen bei mir wieder runter.
Ebenfalls wird man das auch bei diversen Firmen haben.

Ein Programm das dies noch nicht kann hat scheinbar die letzten 20 Jahre nicht so richig mitbekommen.
Seit NT sind die Regeln bekannt.
Ab Vista wurden die Regeln mit der UAC verschärft eingesetzt.

[EWeiss]

Zitat:

Ein Programm das dies noch nicht kann hat scheinbar die letzten 20 Jahre nicht so richig mitbekommen.

VB6 wird von M$ weiterhin in allen Versionen von Windows unterstützt (Abgesehen von der IDE selbst) du scheinst etwas miss zu verstehen denn es ist legitim auch heute noch VB6 Anwendungen zu programmieren.

Mache es mal oder versuche es nur einmal in kleinem Stil dann wirst du erkennen das nicht alles so leicht dahingeklatscht werden kann wie in Delphi.
Es gibt kein Windows, System, Classes oder was ihr sonst noch so alles Vordefiniert bekommt da ist Handarbeit angesagt
auch einer der Gründe wo ich erkenne das viele Delphi Programmierer meist mit der WinApi32 überhaupt nicht zurecht kommen halt nur mit dem was Die Entwickler Umgebung von Delphi bereitgestellt hat ansonsten seit ihr doch aufgeschmissen.
Versuche doch mal die ITaskarList3 oder die Core Audio, IShellInterface in VB6 zu implementieren wenn du nichts hast.. Ich glaube da wärst du aufgeschmissen und wirst versagen..
Sorry aber so sehe ich das.

VB6 hat nun mal den Installation Pfad unter Program Files(x86) und das macht alle daraus resultierenden Probleme fast nicht lösbar was sich wie im Besipiel genannt schon beim kompilieren der Anwendung bemerkbar macht.
Aber das soll mich nicht davon abbringen mein Programm weiterhin zu nutzen und funktionstüchtig zu machen auch wenn das Resultat dieses ist das ich die Installation in einem nicht System spezifischen Order erstelle.
Glücklicher weise muss ich dich damit nicht behelligen so das du meine Anwendung erst gar nicht aus deinem System entfernen must.

Nebenbei das hat nichts mit dem Programmierer zu tun sondern mit den Gegebenheiten.
Das ich programmieren kann muss ich nicht erst noch beweisen bei meinen hier vorgestellten Projekten.

Zitat:

Für einen Musikplayer sollte doch ein einfacher Zugriff reichen

Bist du sicher? Mit meinen TypeLibs, ActiveX Dll's, OCX usw.. wenn dem so wäre würde mein Programm und VB6 unter besagten Pfad auch korrekt funktionieren.
Dem ist leider nicht so denn es ist immer wieder etwas anderes.
Zudem ist es kein Musikplayer sondern ein Multimedia Player mit dem ich sogar unter Win7 noch auf meinem PC Fernsehen konnte.
Leider musste ich diese Funktion deaktivieren da die Treiber unter Win10 nicht mehr funktionieren. (Nun Win10 mal wieder )

Zitat:

Kurzum: Bei alten Delphis kann man glaube ich den Standard-Projekte Ordner selbst einstellen, sobald man den nicht mehr unter C:/Programme hat, sollte es auch ohne Adminrechte gehen. Ich vermute bei VB6 ähnliches.

Nein ist es nicht.
Wenn ich in Delphi eine DLL dynamisch lade spielt es keine rolle wo sich diese befindet.
Bsp. MediaInfo.dll
In VB6 muss sich diese Datei um die Anwendung debuggen zu können im Pfad von VB6.exe befinden und zusätzlich im Anwendungspfad ansonsten wird sie nicht gefunden.
Du siehst also ich habe immer wieder irgendwelche negativen Einflüsse auf das verhalten von VB6 wenn die Anwendung unter Program Files(x86) kompiliert und oder Debuggt wird.

Bisher laufen meine Delphi Programme alle unter Program Files(x86) toi, toi aber selbstverständlich ist das nicht.
Wie gesagt irgendwie sinnlos dieser Ordner.

gruss

[sakura]

Zitat von EWeiss:

VB6 wird von M$ weiterhin in allen Versionen von Windows unterstützt [...] es ist legitim auch heute noch VB6 Anwendungen zu programmieren.

Zitat:

Legitim: gesetzlich anerkannt, rechtmäßig; im Rahmen bestimmter Vorschriften [erfolgend]

Aber was Du wohl meinst, ist, dass MS Dich aktiv unterstützt, VB6 unter Win10 einzusetzen. Und kurz: dem ist nicht so. VB6 ist von 1998, damals gab es ganz, ganz andere Voraussetzungen. Auch wenn Du es noch schaffen magst, ein unter VB6 erstelltes Programm unter Win10 zum Laufen zu bekommen, aktiv unterstützen tut das niemand bei MS. Auch wenn man sich bei der Weiterentwicklung von Windows größte Mühe gibt, dass ältere Programme weiterhin laufen, so will niemand dort aktiv, dass heute noch jemand VB6 nutzt, um neue Programme zu entwickeln.

Zitat von EWeiss:

VB6 hat nun mal den Installation Pfad unter Program Files(x86) und das macht alle daraus resultierenden Probleme fast nicht lösbar

Andere Zeiten, andere Sitten, auch bei MS. Was damals allgemein gemacht wurde, war oft auch schon damals entgegen der Richtlinien. Leider wurden auch bei MS diese oft ignoriert, was dieses Verhalten keineswegs verbessert oder gar rechtfertigt.

Zitat von EWeiss:

Bisher laufen meine Delphi Programme alle unter Program Files(x86) toi, toi aber selbstverständlich ist das nicht.

An und für sich schon, wenn Du Dich an die Regeln des genutzten Betriebssystems hältst.

Zitat von EWeiss:

Wie gesagt irgendwie sinnlos dieser Ordner.

Das ist das was Du lesen willst, aber eventuell liest Du noch einmal alles durch. Du bist da eindeutig recht allein in Deiner Ansicht. Warum nur...

......

[EWeiss]

Zitat:

Warum nur...

Die Spekulation darüber überlasse ich gerne dir.
Aber Entwickle mal ein Programm in VB6 dann können wir uns anschließend über deine Spekulationen weiterhin unterhalten PM natürlich
Du solltest dann aber zeit mit bringen denn es sei dir versichert es wird dir nichts vorgekaut so wie es in Delphi gang und gäbe ist.

Zitat:

Aber was Du wohl meinst, ist, dass MS Dich aktiv unterstützt, VB6 unter Win10 einzusetzen. Und kurz: dem ist nicht so

Informiere dich doch besser erst einmal.
Was definitiv nicht unterstützt wird ist Delphi! Warum nur...
DuckDuck mal.. nach "VB6 und Windows 10"
Ich mache es dir leichter!

Zitat:

Microsoft will continue to support the Visual Basic 6.0 runtime on supported Windows versions for the support lifetime of those operating systems.

Was verstehst du unter "Hall of Fame" nicht?

Es werden weiterhin die Service Packs, Runtime usw.. bei M$ zum Download angeboten. Das ist keine Unterstützung?
Es werden weiterhin Laufzeit Bibliotheken bei der Installation von Windows 10 direkt mit installiert.
Dann weis ich leider nicht was du sonst unter Support verstehst.

Zitat:

Legitim: gesetzlich anerkannt, rechtmäßig; im Rahmen bestimmter Vorschriften [erfolgend]

Du musst mir nicht erklären was Legitim ist.

Zitat:

so will niemand dort aktiv, dass heute noch jemand VB6 nutzt

Erzähle das mal den Menschen die VB6 heute noch aktiv einsetzen 6 > 10 > 20 Millionen Entwickler?
Schaue doch einfach mal wie viele User hier Online sind inklusive Gäste mehr als zur zeit hier auf der DP soviel dazu.
http://www.vbforums.com/forumdisplay...-6-and-Earlier

Zitat:

Leider wurden auch bei MS diese oft ignoriert

M$ ist der Boss und du kannst den Boss nicht vorschreiben was er zu tun und zu lassen hat. Da gibt es kein leider!

Ok wir schweifen ab..

gruss

[sakura]

Zitat von EWeiss:

Aber Entwickle mal ein Programm in VB6 dann können wir uns anschließend über deine Spekulationen weiterhin unterhalten PM natürlich

Du musst mir dazu nicht viel erklären, ich habe es an der Uni 1998/1999 unterrichtet. Also keine Sorge, ich kenne die Unterschiede nur zu gut.

Zitat von EWeiss:

Informiere dich doch besser erst einmal. ... DuckDuck mal.. nach "VB6 und Windows 10"

Auch da steht, dass, was ich geschrieben habe. Man bemüht sich Anwendungen, welche damit entwickelt wurden, am Laufen zu halten, nicht VB6 selbst.

Zitat von EWeiss:

Du musst mir nicht erklären was Legitim ist.

Dann nutze es korrekt

Aber zurück zu Deiner Frage:

Zitat von EWeiss:

Zitat:

[Du bist da eindeutig recht allein in Deiner Ansicht.] Warum nur...

Die Spekulation darüber überlasse ich gerne dir.

Die Spekulationen, warum jeder was anderes sagt, als Du hören willst? Weil Du einfach mal falsch liegst...

.....

[TiGü]

Zitat von EWeiss:

Zitat:

Aber was Du wohl meinst, ist, dass MS Dich aktiv unterstützt, VB6 unter Win10 einzusetzen. Und kurz: dem ist nicht so

Informiere dich doch besser erst einmal.
Was definitiv nicht unterstützt wird ist Delphi! Warum nur...
DuckDuck mal.. nach "VB6 und Windows 10"
Ich mache es dir leichter!

Aus deinen Link:

Windows operating system	VB6 IDE has support?
Windows 10, all 32-bit editions	No
Windows 10, all 64-bit editions	No

[jaenicke]

Zitat von EWeiss:

Versuche doch mal die ITaskarList3 oder die Core Audio, IShellInterface in VB6 zu implementieren wenn du nichts hast..

Der Punkt ist, dass es in VB6 ja offenbar nicht richtig funktioniert während es in Delphi, wenn man das ITaskbarList3 Interface integriert mit und ohne Adminrechte vollkommen normal funktioniert, auch mit den Buttons. VLC und andere Programme zeigen ja auch diese Buttons an und es klappt egal ob mit oder ohne Adminrechten.

Von der Implementierung her sehe ich zwischen Delphi und VB6 (abgesehen von der ganz persönlich für mich schrecklichen VB6 Syntax) keine großen Unterschiede bei dem Interface. Es ist etwas umständlicher, aber das war zu der Zeit halt auch üblich. Andere Sprachen waren da auch noch deutlich rudimentärer.

[EWeiss]

Zitat:

wenn man das ITaskbarList3 Interface integriert mit und ohne Adminrechte vollkommen normal funktioniert

Wo du keinen Anteil dran hast oder?
Ich will damit sagen du verwendest fertig vorhandene Komponente.

Zitat:

auch mit den Buttons

Dann liest du nicht richtig was ich geschrieben habe.

Zitat:

VLC und andere Programme zeigen ja auch diese Buttons an und es klappt egal ob mit oder ohne Adminrechten

Ich weis nicht was du unter Button verstehst.. niemand hat geschrieben das die Button nicht angezeigt werden sie haben beim klick nur keine Auswirkung.

Für die Overlay Button..

Deaktiviere unter Personalisieren\Taskleiste.. Badges auf Taskleiste danach kannst du mir sagen ob es noch funktioniert!
Das hat nichts aber auch gar nichts mit meiner Implementierung zu tun sondern damit das Win10 sich in allem Einmischt. Warum braucht man dafür einen Systemsteuerungseintrag?
Welcher sinn steckt dahinter.

Da du anscheinend sehr viel zu wissen scheinst.. sage mir bitte was bei meiner Implementierung (Code) falsch sein soll.

Code:

[
  uuid(a8ce1d71-bfd6-4b55-990a-be75aeb926b8),
  helpstring("Taskbar API for VisualBasic (Windows 10)"),
  version(1.0)
]

library TaskbarAPI
{
  typedef struct UUID
  {
    long Data1;
    short Data2;
    short Data3;
    unsigned char Data4[8];
  } UUID;
  typedef UUID *REFGUID;
  typedef [public] UUID IID;
  typedef UUID *REFIID;
  typedef [public] UUID CLSID;
  typedef UUID *REFCLSID;
  typedef [public] UUID GUID;

  typedef struct RECT
  {
    long Left;
    long Top;
    long Right;
    long Bottom;
  } RECT;

  typedef struct FILETIME
  {
    long LowDateTime;
    long HighDateTime;
  } FILETIME;

  typedef struct WIN32_FIND_DATAW
  {
    long FileAttributes;
    FILETIME CreationTime;
    FILETIME LastAccessTime;
    FILETIME LastWriteTime;
    long FileSizeHigh;
    long FileSizeLow;
    long Reserved0;
    long Reserved1;
    unsigned char FileName[520];
    unsigned char AlternateFileName[28];
  } WIN32_FIND_DATAW;

  typedef struct PROPERTYKEY
  {
    UUID fmtid;
    long pid;
  } PROPERTYKEY;

  typedef struct PROPVARIANT
  {
    short vt;
    short wReserved1;
    short wReserved2;
    short wReserved3;
    long val;
  } PROPVARIANT;

  typedef enum SLGPConstants
  {
    SLGP_SHORTPATH = 0x1,
    SLGP_UNCPRIORITY = 0x2,
    SLGP_RAWPATH = 0x4,
    SLGP_RELATIVEPRIORITY = 0x8
  } SLGPConstants;

  typedef enum SLRConstants
  {
    SLR_NO_UI = 0x0001,
    SLR_UPDATE = 0x0004,
    SLR_NOUPDATE = 0x0008,
    SLR_NOSEARCH = 0x0010,
    SLR_NOTRACK = 0x0020,
    SLR_NOLINKINFO = 0x0040,
    SLR_INVOKE_MSI = 0x0080,
    SLR_NO_UI_WITH_MSG_PUMP = 0x0101,
  } SLRConstants;

  typedef enum KNOWNDESTCATEGORYConstants
  {
    KDC_FREQUENT = 0x1,
    KDC_RECENT = 0x2
  } KNOWNDESTCATEGORYConstants;

  typedef enum TBPFLAG
  {
    TBPF_NOPROGRESS     = 0x00000000,
    TBPF_INDETERMINATE  = 0x00000001,
    TBPF_NORMAL         = 0x00000002,
    TBPF_ERROR          = 0x00000004,
    TBPF_PAUSED         = 0x00000008,
  } TBPFLAG;


  [
    uuid(00000000-0000-0000-C000-000000000046),
    version(1.0),
    helpstring("IUnknown-Interface for Visual Basic"),
    odl
  ]
  interface IVBUnknown
  {
    long __stdcall QueryInterface([in] UUID* IID, [in,out] void* pObject);
    long __stdcall AddRef();
    long __stdcall Release();
  };

  [
    uuid(000214F9-0000-0000-C000-000000000046),
    version(1.0),
    helpstring("IShellLinkW-Interface for Visual Basic"),
    odl
  ]
  interface IVBShellLinkW : IVBUnknown
  {
    long __stdcall GetPath([in,out] LPWSTR Path, [in] int Pathsize, [in,out] WIN32_FIND_DATAW *FileData, [in] SLGPConstants Flags);
    long __stdcall GetIDList([in,out] long *pIDL);
    long __stdcall SetIDList([in] long pIDL);
    long __stdcall GetDescription([in,out] LPWSTR Descr, [in] int Buffersize);
    long __stdcall SetDescription([in] LPWSTR Descr);
    long __stdcall GetWorkingDirectory([in,out] LPWSTR WorkingDir, [in] int Buffersize);
    long __stdcall SetWorkingDirectory([in] LPWSTR WorkingDir);
    long __stdcall GetArguments([in,out] LPWSTR Args, [in] int Buffersize);
    long __stdcall SetArguments([in] LPWSTR Args);
    long __stdcall GetHotkey([in,out] short *Hotkey);
    long __stdcall SetHotkey([in] short Hotkey);
    long __stdcall GetShowCmd([in,out] int *ShowCmd);
    long __stdcall SetShowCmd([in] int ShowCmd);
    long __stdcall GetIconLocation([in,out] LPWSTR IconPath, [in] int IconPathSize, [in,out] int *iIcon);
    long __stdcall SetIconLocation([in] LPWSTR IconPath, [in] int iIcon);
    long __stdcall SetRelativePath([in] LPWSTR RelPath, [in] long reserviert);
    long __stdcall Resolve([in] long hWnd, [in] SLRConstants Flags);
    long __stdcall SetPath([in] LPWSTR Path);
  };

  [
    uuid(886D8EEB-8CF2-4446-8D02-CDBA1DBDCF99),
    version(1.0),
    helpstring("IPropertyStore for Visual Basic"),
    odl
  ]
  interface IVBPropertyStore : IVBUnknown
  {
    long __stdcall GetCount([in] long* cProps);
    long __stdcall GetAt([in] long iProp, [in] PROPERTYKEY* pKey);
    long __stdcall GetValue([in] PROPERTYKEY* key, [in,out] PROPVARIANT* pv);
    long __stdcall SetValue([in] PROPERTYKEY* key, [in] PROPVARIANT* propvar);
    long __stdcall Commit();
  };

  [
    uuid(92CA9DCD-5622-4bba-A805-5E9F541BD8C9),
    version(1.0),
    helpstring("IObjectArray-Interface for Visual Basic"),
    odl
  ]
  interface IVBObjectArray : IVBUnknown
  {
    long __stdcall GetCount([out] long* pcObjects);
    long __stdcall GetAt([in] long uiIndex, [in] UUID* riid, [in,out] void* ppv);
  };

  [
    uuid(5632b1a4-e38a-400a-928a-d4cd63230295),
    version(1.0),
    helpstring("IObjectCollection-Interface for Visual Basic"),
    odl
  ]
  interface IVBObjectCollection : IVBObjectArray
  {
    long __stdcall AddObject([in] IVBUnknown* punk);
    long __stdcall AddFromArray([in] IVBObjectArray* poaSource);
    long __stdcall RemoveObjectAt([in] long uiIndex);
    long __stdcall Clear();
  };

  [
    uuid(6332debf-87b5-4670-90c0-5e57b408a49e),
    version(1.0),
    helpstring("ICustomDestinationList-Interface for Visual Basic"),
    odl
  ]
  interface IVBCustomDestinationList : IVBUnknown
  {
    long __stdcall SetAppID([in] long pszAppID);
    long __stdcall BeginList([out] long* pcMinSlots, [in] UUID* riid, [in,out] void* ppv);
    long __stdcall AppendCategory([in] long pszCategory, [in] IVBObjectArray* poa);
    long __stdcall AppendKnownCategory([in] KNOWNDESTCATEGORYConstants category);
    long __stdcall AddUserTasks([in] IVBObjectArray* poa);
    long __stdcall CommitList();
    long __stdcall GetRemovedDestinations([in] UUID* riid, [in,out] void* ppv);
    long __stdcall DeleteList([in] long pszAppID);
    long __stdcall AbortList();
  };

  [
    uuid(ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf),
    helpstring("ITaskbarList-Interface for Visual Basic"),
    odl
  ]
  interface IVBTaskbarList : IVBUnknown
  {
    long __stdcall HrInit();
    long __stdcall AddTab([in] LONG hwnd);
    long __stdcall DeleteTab([in] LONG hwnd);
    long __stdcall ActivateTab([in] LONG hwnd);
    long __stdcall SetActiveAlt([in] LONG hwnd);
    long __stdcall MarkFullscreenWindow([in] LONG hwnd,[in] LONG fFullscreen);
    long __stdcall SetProgressValue([in] LONG hwnd,[in] LONG ullCompleted_Low,[in] LONG ullCompleted_High,[in] LONG ullTotal_Low,[in] LONG ullTotal_High);
    long __stdcall SetProgressState([in] LONG hwnd,[in] TBPFLAG tbpFlags);
    long __stdcall RegisterTab([in] LONG hwndTab,[in] LONG hwndMDI);
    long __stdcall UnregisterTab([in] LONG hwndTab);
    long __stdcall SetTabOrder([in] LONG hwndTab,[in] LONG hwndInsertBefore);
    long __stdcall SetTabActive([in] LONG hwndTab,[in] LONG hwndMDI,[in] LONG dwReserved);
    long __stdcall ThumbBarAddButtons([in] LONG hwnd,[in] LONG cButtons,[in] LONG pButton);
    long __stdcall ThumbBarUpdateButtons([in] LONG hwnd,[in] LONG cButtons,[in] LONG pButton);
    long __stdcall ThumbBarSetImageList([in] LONG hwnd,[in] LONG himl);
    long __stdcall SetOverlayIcon([in] LONG hwnd,[in] LONG hIcon,[in] LONG pszDescription);
    long __stdcall SetThumbnailTooltip([in] LONG hwnd, [in] LONG pszTip);
    long __stdcall SetThumbnailClip([in] LONG hwnd, [in] RECT *prcClip);
  };
}

Bedenke es handelt sich hier um eine *.tlb Lib die im System registriert werden muss. (In Delphi auch? Denke mal nicht)
Und hier liegt der Unterschied bzw.. kann ein Problem entstehen wenn ich etwas registrieren muss mit Adminrechten die TypleLib sie aber nicht braucht.

PS:
Nochmal es hat immer funktioniert nur nicht unter Win10!

Zitat:

Von der Implementierung her sehe ich zwischen Delphi und VB6 (abgesehen von der ganz persönlich für mich schrecklichen VB6 Syntax)

Ich will dir nicht zu nahe treten aber sorry du hast einfach keine Ahnung von der Materie btw. den Unterschieden zwischen VB6\Delphi
Dafür muss man sich erstmal wirklich damit beschäftigt haben es gibt keine Interface Implementierung für ITaskbarList3 denn das ist schlichtweg in VB6 gar nicht möglich nur über eine eigens in C++ erstellte TypeLib.
Nun welche Syntax ist besser die von C++ oder diese von Delphi darüber kann man wahrlich streiten.


gruss