Program Files(x86) überhaupt noch sinngemäß

[EWeiss]

Habe jetzt den Installationspfad meines Programms (aller Programme) auf C:\User\UserName\AppData\Roaming verlegt weil unter Program Files(x86)
einfach zu viele Einschränkungen vorhanden sind die einen vernünftigen Start der Anwendung mit all seinen Dateizugriffen strikt verhindert.

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.

Meine Meinung dazu! Keine! Er ist einfach sinnlos.

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.

Jetzt starte ich VB6 mit Adminrechten der Fehler kommt logischerweise nicht mehr vor dafür aber andere.
Ich kann dann mit meinem Programm die ITaskbarList3 nicht mehr debuggen weil keine Funktion warum auch immer weitergeleitet wird.
Starte ich VB6 ohne Adminrechte funktioniert alles bis auf diverse Probleme die VB6 selbst blockieren.
Ich kann dann zum Beispiel keine Anwendung mehr in meinem Anwendungspfad erstellen weil die benötigten rechte fehlen.

Program Files? Was für Program Files welche Daten soll man da noch ablegen wenn diese von allen Seiten vom System heraus in ihrer Funktionsweise blockiert werden.
Selbst Spiele Anwendungen die immer diesen Pfad zur Installation angeben funktionieren nicht mehr ohne Adminrechte.
Von daher ist es uninteressant für einen Anwender auf 1 Computer diesen Pfad überhaupt noch zu wählen..
Es ist etwas anderes wenn mehrere User den Computer verwenden aber wann ist das schon der Fall?

Also abschließend dieser Ordner hat für mich einfach keine Berechtigung mehr.
Wollte das nur mal loswerden.

gruss

[Daniel]

Naja, ProgramFiles ist halt immer noch der vom Hersteller vorgesehene lokale Ordner für Installationen. Ja, es gibt da besondere Einschränkungen, deren Sinnhaftigkeit sich bei manchen mehr, bei manchen weniger schnell erschließt.
Der Roaming-Ordner macht halt das, was er soll: Wenn die Infrastruktur es vorsieht, dass Benutzer mit ihren Profilen an mehren Rechnern arbeiten können, dann wandert der Inhalt dieses Ordners mit. Das ist in vielen Fällen durchaus sinnvoll, wird aber erschwert, wenn jeder alles in besagten Ordner kopiert. Dafür ist er nicht vorgesehen und ein Domänen-Admin kann einem da schnell mal quer kommen.

AppData ist keine Entsprechung zu ProgramFiles.

[EWeiss]

Zitat:

Dafür ist er nicht vorgesehen und ein Domänen-Admin kann einem da schnell mal quer kommen.

Ja durchaus schlüssig nur wann befindet man sich als Privat Anwender und das ist nun mal die Masse in einer Domäne?

Zitat:

AppData ist keine Entsprechung zu ProgramFiles.

Mag so sein aber die einzige Alternative damit man ohne Kontrolle, Einschränkung mit seinem\einem Programm arbeiten kann.
Ja ich kann mein Programm so auslegen das es alle Berechtigungen erhält.. NUR wie in meinem Beispiel selbst wenn funktionieren sie nicht mehr so wie sie sollen
denn irgendwo ist immer etwas anderes was dann nicht mehr funktioniert.

PS:
VB6 ist in der "Hall of Fame" und wird nach Aussagen von M$ mit jeder Windows Version kompatibel sein auch wenn es für die IDE keinen Support mehr gibt.
Wenn dem so ist.. dann sollten sie es richtig machen oder es ganz einstellen. (Nur so nebenbei)

gruss

[Dalai]

Programme haben schon aus einem einfachen Grund im %ProgramFiles% zu liegen: Damit Nutzer an den Executables und DLLs keine Änderungen vornehmen können, ihnen DLLs unterschieben können, um z.B. irgendwelche Lücken der Programme auszunutzen, um z.B. an höhere Rechte zu gelangen. Weiterhin werden Verschlüsselungstrojaner wirksam eingeschränkt, wenn an möglichst wenigen Stellen Schreibrechte vorhanden sind. Und: Software Restriction Policies lassen sich geordnet und erheblich einfacher umsetzen.

Deine Schwierigkeiten mit %ProgramFiles% sind außerdem keinesfalls allgemeingültig.

Grüße
Dalai

[Alallart]

Zitat:

Zitat von EWeiss (Beitrag 1423652)

Welche Funktion hat dieser Ordner noch?

Den Schutz der Daten. Das Problem ist nicht der Ordner Program Files(x86), sondern eher die der Programmierer, die falsch programmieren. Das Problem was du hast ist IMHO weniger das Problem das Ordners, als das Problem des Programmierers.

Die Daten im Ordner Program Files(x86) sind vom System geschützt. Niemand außer dem Administrator kann sie ändern oder löschen. So ist das gewollt. Deshalb gehören dort alle Daten die geschützt werden müssen, z. B. EXE-Files, usw.

Nur glauben viele Programmierer dort auch ihre Ini (oder Ähnliches) ablegen zu können. Dafür ist der Ordner aber nicht gedacht.

Wenn du also nun deine Programme in AppData\Roaming ablegst, kann jeder Virus sie kompromittieren. Denn dieser Ordner wird nicht vom System geschützt. Auch können andere Programme in den Ordner etwas reinschreiben und so die Funktionsweise ändern. Oder irgendwer löscht einfach den Ordner.

Kein Program Files(x86), kein Schutz durch das System (meine Meinung).

[Alallart]

Nochwas, ich habe das VB6 übersehen. Laut Wikipedia ist VB6 von 1998. Das ist die Zeit von Windows 95 und 98. Für die beiden Betriebssysteme galten noch andere Regeln. Die kannten zwar schon den Programme-Ordner, der war aber kein (vom System) schreibgeschützter (bzw. gesicherter) Ordner. Da konnte jeder noch reinschreiben. Die Probleme fingen erst mit Windows XP, denn da wurden NT (Profi-Betriebssystem) und 9x (Konsumenten-Betriebssicherstem) vereinigt.

Um auf den Punkt zu kommen, viele (selbst professionelle) Programme die vor 2001 entwickelt wurden haben mit dem Ordner ihre Probleme.

[jfheins]

Zitat:

Zitat von EWeiss (Beitrag 1423652)

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:

Zitat von EWeiss (Beitrag 1423652)

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

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1423668)

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:

Zitat von EWeiss (Beitrag 1423677)

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:

Zitat von EWeiss (Beitrag 1423677)

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:

Zitat von EWeiss (Beitrag 1423677)

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:

Zitat von EWeiss (Beitrag 1423677)

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... :gruebel:

...:cat:...

[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:

Zitat von EWeiss (Beitrag 1423677)

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:

Zitat von EWeiss (Beitrag 1423755)

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:

Zitat von EWeiss (Beitrag 1423755)

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

[EWeiss]

Zitat:

Zitat von Daniel (Beitrag 1423760)

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.

Ja Daniel sorry du hast natürlich recht!
Deshalb sagte ich im vorherigen Beitrag ja auch "Ok wir schweifen ab.."

Denke die frage ist für mich beantwortet. Danke an alle die sich beteiligt haben.
Für mich hat der Ordner in Verbindung mit VB6! keinerlei Berechtigung mehr er macht mehr kaputt als das er irgendeinen nutzen hat
weil Kompilieren ausführen von Anwendungen in VB6 erstellt schlichtweg unmöglich ist.

gruss

[sakura]

Zitat:

Zitat von EWeiss (Beitrag 1423740)

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:

Zitat von EWeiss (Beitrag 1423740)

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:

Zitat von EWeiss (Beitrag 1423740)

Du musst mir nicht erklären was Legitim ist.

Dann nutze es korrekt ;-)

Aber zurück zu Deiner Frage:

Zitat:

Zitat von EWeiss (Beitrag 1423740)

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

..:cat:...

[EWeiss]

Zitat:

nicht VB6 selbst.

Nur um zum ende zu kommen.. wie Daniel schon sagt wir driften inhaltlich gerade ab.

Die Unterstützung der Runtime und Abhängigkeiten zählt für mich dazu wenn du der Meinung bist das es nicht zutrifft dann soll es so sein.
Es wird nur müßig darüber noch zu diskutieren.
Die Gedanken sind bekanntlich frei ;)

Zitat:

Weil Du einfach mal falsch liegst...

Möchte ich sehr bezweifeln.
Nur Ich kann in dem fall beurteilen ob etwas läuft oder nicht bzw. wie die zusammenhänge hier sind.

Zitat:

Du musst mir dazu nicht viel erklären, ich habe es an der Uni 1998/1999 unterrichtet.

Lang, lang ist's her vielleicht frischst du deine Erkenntnisse nochmal etwas auf. ;)

Ihr könnt nun gerne weiter diskutieren für mich ist das Thema abgehandelt.

gruss

[sakura]

Zitat:

Zitat von EWeiss (Beitrag 1423765)

Zitat:

Weil Du einfach mal falsch liegst...

Möchte ich sehr bezweifeln.

Weil Dein Programm nicht läuft, wie Du es erwartest, bezweifelst Du ein ganzes, weltweit genutztes Konzept... :gruebel:

Zitat:

Zitat von EWeiss (Beitrag 1423765)

Nur Ich kann in dem fall beurteilen ob etwas läuft oder nicht bzw. wie die zusammenhänge hier sind.

Klar, Dein Programm können wir nicht beurteilen, es ging in der Ausgangsfrage aber auch ums Konzept, nicht ein problematisch entwickeltes Programm.

Zitat:

Zitat von EWeiss (Beitrag 1423765)

Ihr könnt nun gerne weiter diskutieren für mich ist das Thema abgehandelt.

Weil Dir die Meinung der anderen nicht gefällt?

...:cat:...

[Alallart]

Zitat:

Zitat von EWeiss (Beitrag 1423762)

Für mich hat der Ordner in Verbindung mit VB6! keinerlei Berechtigung mehr er macht mehr kaputt als das er irgendeinen nutzen hat
weil Kompilieren ausführen von Anwendungen in VB6 erstellt schlichtweg unmöglich ist.

Ich kenne VB6 nicht, aber, aber deine Aussage: "Für mich hat der Ordner in Verbindung mit VB6! keinerlei Berechtigung" finde ich übertrieben. Das klingt für mich nach: "Ich war streng gläubiger Katholik, ich bin konvertiert, jetzt bin ich streng gläubiger Protestant. Für mich ergeben katholische Kirchen jetzt keine Berechtigung mehr, sie können alle abgerissen werden."

Für mich ist das installieren von Programmen in AppData\Roaming eine Unsitte, die davon kommt, dass einige Programme ihre Daseinsberechtigung nur noch in automatischen Updates sehen, wie z. B. Google Chrome. Die können ihre Updates nicht so leicht in Program Files(x86) Ordner machen.

Nur ergibt sich aus der Unsitte Programmen in AppData\Roaming zu installieren ein großes Problem. Unter normalen Umständen kann sich ein Virus (abgesehen er wurde mit Adminrechten gestartet) nirgendwo im System festbeißen. Er hat kein Zugriff auf die Programme im Program Files(x86) Ordner. Er hat jetzt aber die Möglichkeit die Programme in AppData\Roaming zu kompromittieren. Auf die hat er Schreibrechte.

Wer also zulässt, dass auf seinem System ungeschützte Programme abgelegt werden, der nimmt in Kauf, dass auf seinem System sich Viren einnisten können.

[Luckie]

Zitat:

das installieren von Programmen in AppData\Roaming

Auf, dass mehrere Gigabyte an Programmdateien im Backup des Benutzerslanden. :roll:

[EWeiss]

Zitat:

Weil Dir die Meinung der anderen nicht gefällt?

Nein weil der Admin sagte das wir zu sehr abdriften.. nicht mehr nicht weniger. Was ist da nicht zu verstehen?
Ich für meinen Teil kann das akzeptieren.

Zitat:

Er hat jetzt aber die Möglichkeit die Programme in AppData\Roaming zu kompromittieren. Auf die hat er Schreibrechte.

Das kann er auch so ohne meine spezielle Anwendung es gibt genügend andere..

Zitat:

Auf, dass mehrere Gigabyte an Programmdateien im Backup des Benutzerslanden.

Ist für mich kein Backup Ordner noch nie gewesen.
Mein System ist das Backup und zwar das vollständige Image davon!
Wer heute noch einen Ordner als Backup ansieht ist selber schuld.. ich persönlich wüsste damit nichts anzufangen.
Wir reden hier von einem Privat Anwender System nicht von einer Domäne die von einem Admin kontrolliert und verwaltet wird.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1423740)

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

[Luckie]

Zitat:

Zitat von EWeiss (Beitrag 1423776)

Zitat:

Auf, dass mehrere Gigabyte an Programmdateien im Backup des Benutzerslanden.

Ist für mich kein Backup Ordner noch nie gewesen.
Mein System ist das Backup und zwar das vollständige Image davon!
Wer heute noch einen Ordner als Backup ansieht ist selber schuld.. ich persönlich wüsste damit nichts anzufangen.
Wir reden hier von einem Privat Anwender System nicht von einer Domäne die von einem Admin kontrolliert und verwaltet wird.

Da von rede ich auch. Und du schließt mal wieder von dir auf die Allgemeinheit. Würde ich kein NAS haben, würde ich, im einfachsten Fall, einfach regelmäßig den Benutzerordner auf einer externen Festplatte sichern. Und wenn dann immer mehrere Gigabyte an Programmdaten im Backup sind weil alle ihre Programme in den Benutzerordner installieren, wäre das, sagen wir mal, etwas "unschön".

[Schokohase]

Ganz nebenbei bemerkt:

Seit Windows 7 gibt es ganz offiziell einen Ordner wo man Programme für einen Benutzer ablegen sollte
FOLDERID_UserProgramFiles
und der verweist auf %LOCALAPPDATA%\Programs.

[generic]

Der Windowsinstaller (bzw. WIX) unterscheidet "per User" oder "per Maschine" Installation.
Bei der ersten Art, können nicht Admins Software installieren - allerdings nur in Ihr eigenes Profil.
Jeder Benutzer der Maschine, muss sich die Software selbst installieren.

Variante Zwei:
Ein Admin muss die Software installieren, diese steht aber dann allen zur Verfügung.

https://www.indigorose.com/webhelp/s...tallations.htm

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1423801)

Zitat:

Zitat von EWeiss (Beitrag 1423740)

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

Hmmm…

Zitat:

VB6 wird von M$ weiterhin in allen Versionen von Windows unterstützt (Abgesehen von der IDE selbst)

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1423833)

Hmmm…

Zitat:

VB6 wird von M$ weiterhin in allen Versionen von Windows unterstützt (Abgesehen von der IDE selbst)

Du nölst halt andauernd wie ein altes Waschweib, dass du nicht mehr auf Windows 10 entwickeln kannst.
Könnte eben ursächlich damit zusammenhängen, gell?^^

[EWeiss]

Zitat:

Könnte eben ursächlich damit zusammenhängen, gell?^^

Auch wenn du wieder beleidigend wirst antworte ich trotzdem.

Nein kann damit nichts zu tun haben.. wie auch? Was hat die IDE mit der kompilierten Anwendung zu tun?
Und stell dir mal vor ich kann auch Anwendungen ohne die IDE kompilieren die funktionieren genauso solange wie alle Laufzeit Bibliotheken registriert und im System installiert sind.

Bist du mit deinen Kompilierten Anwendungen in Delphi egal wie schlecht die IDE läuft siehe (RIO) abhängig von der IDE?
Überlege doch mal was du hier schreibst.

PS:

Zitat:

dass du nicht mehr auf Windows 10 entwickeln kannst.

Ich kann sehr gut sogar aber nicht unter Program Files(x86) das ist der feine Unterschied.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1423842)

Nein kann damit nichts zu tun haben.. wie auch? Was hat die IDE mit der kompilierten Anwendung zu tun?
Und stell dir mal vor ich kann auch Anwendungen ohne die IDE kompilieren die funktionieren genauso solange wie alle Laufzeit Bibliotheken registriert und im System installiert sind.

Bist du mit deinen Kompilierten Anwendungen in Delphi egal wie schlecht die IDE läuft siehe (RIO) abhängig von der IDE?
Überlege doch mal was du hier schreibst.

Gleich im ersten Post dieses Threads beschwerst du dich, dass die VB6-IDE wie ein Sack Nüsse läuft.
Überlege doch mal was du hier schreibst! :roll:

Zitat:

Zitat von EWeiss

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.

Jetzt starte ich VB6 mit Adminrechten der Fehler kommt logischerweise nicht mehr vor dafür aber andere.
Ich kann dann mit meinem Programm die ITaskbarList3 nicht mehr debuggen weil keine Funktion warum auch immer weitergeleitet wird.
Starte ich VB6 ohne Adminrechte funktioniert alles bis auf diverse Probleme die VB6 selbst blockieren.
Ich kann dann zum Beispiel keine Anwendung mehr in meinem Anwendungspfad erstellen weil die benötigten rechte fehlen.

[EWeiss]

Zitat:

Gleich im ersten Post dieses Threads beschwerst du dich, dass die VB6-IDE wie ein Sack Nüsse läuft.

Mittlerweile sind wir 4 Seiten weiter und so wie ich schrieb arbeite ich nicht mehr unter Program Files(x86)
Von daher ist das Problem erledigt.

Und egal wie die IDE läuft die Kompilierte Anwendung läuft so wie sie soll, nochmal außerhalb "Program Files(x86)"

gruss

[TiGü]

Gewöhne dir einfach an alte Software, die vor Windows XP raus kam, einfach abseits von "Program Files(x86)" und "Program Files" zu installieren. Dann hast du keine Probleme!
So mach ich das bspw. auch mit alten Spielen von GOG.com (z.B. Dungeon Keeper II, Thief). Die kommen einfach in ein C:\Games\... Unterordner und fertig.
Wenn deine Software auch aus den Zeitraum ist (oder mit Werkzeugen aus der Zeit), dann verfahre bitte genauso.

Es ist alles nicht so schwer und oft ist Layer 8 das Problem!

[hoika]

Hallo,

Zitat:

Von daher ist das Problem erledigt.

Und die Lösung hast Du auch gepostet.

So kann dieser Thread auch als gelöst geschlossen werden.

Alles ist gut. Wir schaffen das. ;)

[EWeiss]

Zitat:

Und die Lösung hast Du auch gepostet.

Dito!
Und daraus resultierend war meine frage ob dieser Folder noch sinngemäß ist.
Nach meiner jetzigen Erfahrung sagen wir mal für ältere Programme nicht mehr.

Zitat:

So kann dieser Thread auch als gelöst geschlossen werden.

:)

gruss

[freimatz]

Zitat:

Zitat von hoika (Beitrag 1423867)

So kann dieser Thread auch als gelöst geschlossen werden.

Bitte nicht. Wir sind doch hier bei Klatsch und Tratsch ("Dies ist der Offtopic-Bereich für alle Themen, die nichts mit der Entwicklung von Software zu tun haben.") und ich habe noch Popcorn da.
:duck: