Program Files(x86) überhaupt noch sinngemäß

[p80286]

Zitat von Bernhard Geyer:

Seit NT sind die Regeln bekannt.

Ach Ja?
Wenn man sich ganz unvoreingenommen dem Thema via Google (o.ä.) nähert, dann trifft man auf jede Menge wolkiger Begriffe wie z.B. "Sicherheit" aber nie auf ein Rechte-Konzept. Und wenn ein offiziell installiertes Programm in einem Unterordner auch Schreibrechte eingerichtet hat... nun ja es wird Gründe haben.
Auch wenn ich Dir inhaltlich voll und ganz zustimmen muß, solange der "Admin" als Allheilmittel für irgendwelche Zugriffsprobleme herhalten muß, solange ist das Unwissen über das Rechtekonzept von Windows weit verbreitet.

Übrigens kein Windowsrechner seit NT, ist nicht in ein logisches Netz eingebunden, in der Standardinstallation.

Gruß
K-H

[Sherlock]

Ich sag es mal so: Alle anderen schaffen ihre Arbeit von "Program Files" aus

Sherlock

[hoika]

Hallo,
naja, fast alle.

Aber leider findet man halt als Anfänger viele alte Quellen mit
with TIniFile.Create(ChangeFileExt(Application.ExeName, '.ini')) do ...

Das klappt ja auch, nur das die Ini in den virtual drives verschwindet

[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

[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

[jaenicke]

Zitat von EWeiss:

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

Per Deklaration des Interfaces analog zur Headerdatei und Nutzung entsprechend der API, was ja nicht sonderlich aufregend ist.

Zitat von EWeiss:

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.

Ich kannte nur diese Art der Implementierung:
https://www.planet-source-code.com/v...xtCodeId=72856
Und das ist zwar umständlicher aufgrund der Eigenheiten von VB6, aber ansonsten nicht besonders stark anders als bei Delphi. Von einer in C++ erstellten Typelib oder ähnlichem sehe ich dabei nichts.

[Daniel]

Moment - Ihr driftet inhaltlich gerade ab.
Begonnen haben wir mit Sinn und mglw. Unsinn der Program Files-Verzeichnisse.
Jetzt sind wir bei der Frage, ob VB6 im Jahre 2019 noch ein adäquates Werkzeug ist, um für Windows 10 zu entwickeln.

[EWeiss]

Zitat:

Von einer in C++ erstellten Typelib oder ähnlichem sehe ich dabei nichts.

Eine TypeLib wird in VB6 als Referenz eingebunden im Code siehst du davon natürlich nichts.

Den link kann ich leider nicht ansehen aber hier kannst du lesen wie ich mein Testprogramm für das Interface erstellt habe.
https://foren.activevb.de/archiv/vb-...list-Win7-VB6/

Man achte auf das Datum 1.9.2010

gruss