PureBoard

Verfasst: **11.01.2026 08:02**

Hallo liebes Forum und Spezialisten,

bei meinem Projekt mit einem UpDate resp. Patch für eine eigene Anwendung,
bin ich auf die Anwendung WinSparkle gestoßen, abgeleitet so wie ich erkennen
konnte aus der Mac Version Sparkle.

Die eigentlich UpDate Funktion wurde angegeben sie als DLL existiert.

https://winsparkle.org/
https://github.com/vslavik/winsparkle

Nun hab ich gesehen, dass aber beim Kompilieren auch lib erzeugt werden.

Inzwischen hab ich bei meinen bestehenden Prozessen festgestellt,
dass eine dll Einbindung nicht immer so einfach ist.
Grundsatz wäre hier also ist der erforderliche Aufwand bei lib
eringer als der von dll ?

Bitte nicht gleich mir den Kopf abreißen, die Suche war dann doch
etwas verwirlich im Bezug dll. Wie in meinem Projekt bereits näher
ufgeführt ist mir bewusst, dass man u. U. einen Wrapper für die dll erstellen muss.

DLL und LIB wären als Source vorhanden von GitHub.
Ich versuche mich auch in das Tutorial "dll" einarbeiten zu können,
das ich auf PureArena gefunden habe.

http://www.purearea.net/pb/german/indexpv.htm
http://www.purearea.net/pb/download/tut ... torial.zip

über die aktualität oder anwendbarkeit mit PB 6 resp. 6.21 / 6.30 sei hier hinweggesehen,
es geht mir eher darum etwas besser das verständnis in PB zu verstehen.

lib sind statische und dll dynamische Bibliotheken, das ist somit klar.

Wenn ich dazu den Befehl Import verwende für die lib, würde diese beim Kompilieren
in das Projekt von pb implementiert und die effektive lib würde nicht mitgegeben werden müssen,
wäre meine Überlegung so auch korrekt? Im Gegensatz zur existierenden Variante mit einer dll.

Was mich etwas verwirrt ist, wenn ich im Source angebe Import "irgendwas.lib"
und diese dann in der exe nicht vorhanden wäre bei der Installation beim "Kunden",
gibt es da nicht einen Error oder ist der Anwendung das in dem Fall egal?

Die Frage ist natürlich sowol als auch, wahrscheinlich als Anfänger Frage möglich asl auch
eine Allgemeine Frage welche sich dann doch ausschliesslich auf einem Windows System bezieht.

Mir war somit nicht klar wo ich besser diese Frage hinstellen sollte.

Herzlich en Dank für die unterstützung
Christian

Verfasst: **11.01.2026 09:22**

Ich kenne mich jetzt zwar nicht so mit .lib aus, aber ich denke :
Wenn bei Import "irgendwas.lib" die .lib schon gar nicht vorhanden
ist, bekommst du schon vom Compiler oder Linker eine Fehlermeldung.
Und die .exe, die du deinem Kunden geben willst, wird erst gar nicht
erstellt. Bei einer .DLL ist das anders, weil die erst zur Laufzeit der .exe
dynamisch geladen wird. Also, wenn die Compilation fehlerfrei durchläuft,
ist auch die .lib automatisch mit eingebunden.
Was die DLL betrift, könntest du diese ja auch mit IncludeBinary in dein
Programm einbinden und beim Start deines Programmes sie wieder in den
Ordner deiner .exe schreiben und anschließend öffnen. Diese Vorgehensweise
habe ich auch schon öfters praktizizert, da meine Kollegen meinten, sie müßten
die .DLL löschen. Dann funktionierte mein Programm nicht mehr.

Verfasst: **11.01.2026 09:45**

Hallo H. Brill,

zu meiner Ehren - Rettung habe ich die Hilfe aus PB dazu herangezogen, mit Import und so.

https://www.purebasic.com/german/docume ... mport.html

Zumindest habe ich es so verstanden, aus dem gegebenen.
Kann sehr gut sein, dass ich da den Text missverstanden habe.

Dann muss ich mich doch noch einiges mehr der gerammten Thematik widmen.

Ich meinte, bei der Kompilierung wäre die lib noch vorhanden, erst nach Kompilierung
und Auslieferung an den Kunden in dem Fall wäre diese nicht mehr erforderlich.

Ich habe es ähnlich dem IncludeBinnary Befehl verstanden, einfach ausschließlich für eine lib Bibliothek.

Das zumindest meine ursprüngliche Idee, wie wenn ich also beim Kompilieren mit IncludeBinary
auch die dll in der exe resp. dem ausführbaren programm mit kompiliere wäre das auch
die dll als separat vorhandene physische Datei nicht mehr erforderlich.

Es würde so auch keinen Error verursachen, so mein Verständnis aus Deinem Post.

Wäre insofern praktisch, als einzelne Teile nicht separat daher kommen.
Wenn ich natürlich GB weise Zusatz habe, würde das eher sinnfrei werden.
Ich beziehe mich eher auf wenige dll resp. lib Bibliotheken welche mitgeliefert würden.

Welche sich im akzeptablen Bereich einer ausführbaren Anwendung bewegen.

Bild

Herzliche Grüße und nachträglich alles Gute im neuen Jahr.

Christian

Verfasst: **11.01.2026 10:14**

Das zumindest meine ursprüngliche Idee, wie wenn ich also beim Kompilieren mit IncludeBinary
auch die dll in der exe resp. dem ausführbaren programm mit kompiliere wäre das auch
die dll als separat vorhandene physische Datei nicht mehr erforderlich.

Als physisch vorhandene Datei muß sie sehr wohl beim Start deines Programmes
da sein. Nur schreibst du sie halt eben beim Start der .exe neu. Hat halt den
Vorteil, daß du sie nicht mehr separat mitliefern mußt.
Eine Ausnahme ist da MemoryModule, wo der Speicherbereich in dem binäre die DLL steckt,
direkt in den Speicher geladen wird. Das wurde dir aber auch schon im Jahre 2024 beantwortet.
Aber, wenn es schon mal eine statische .lib dafür gibt, würde ich diese bevorzugen.

Verfasst: **11.01.2026 10:21**

Vor allem weil es gerade um "Updates" geht, sollte man sich 5x überlegen, alles in die Executable zu schmeißen. Da bei Purebasic in der Regel immer mit dem aktuellen integrierten Stand der Libraries kompiliert wird, ist die Versionsnummer von Purebasic schon einmal ein wichtiges Indiz, ob die Exe geupdated werden muss oder nicht. Klar wenn man selber Änderungen am Code vorgenommen hat, muss die Exe auch aktualisiert werden. Wenn eine Library aktualisiert wurde, reicht es nur diese zu aktualisieren. Wenn man sie statisch in die Exe linkt bedeutet das, das die komplette Exe getauscht werden muss. Vor allem Libraries mit ständigen Updates sollten immer als DLL eingebunden werden. Hat man aber etwas grundlegendes, was sowieso immer mitgegeben und selten aktualisiert wird, kann man die Lib ins Programm direkt mit aufnehmen.

WinSparkle scheint das Tool für das Update mitzuliefern und ist komplett in der DLL enthalten. Wie du da auf Lib kommst, weiß ich nicht. Laut den Docs ist es eine "self-contained DLL" mit normaler Header Datei.

Code: Alles auswählen

#include <winsparkle.h>

Die DLL muss immer im Kontext anwesend sein. Das Programm "könnte" zwar starten (wenn man es später eingebunden hat). Aber warum man es dann überhaupt einbindet, verstehe ich nicht. Es soll sein Tool aktuell halten und das Werkzeug dazu würde man nicht mitliefern? So ganz verstehe ich deinen Gedankengang nicht. Das ist genauso wie "meine Kunden löschen die DLLs immer". Na und? Das ist kein Problem des Entwicklers! Software wird so ausgeliefert, wie sie entwickelt wurde. Wenn irgendeiner glaubt es besser zu wissen, dann ist seine eigene Dummheit auch sein eigenes Problem?!? o.O

Halte dich am besten einfach an die Docs. Da steht drin, wie man das machen muss. Und sieht auch sehr Einfach aus. Es gibt hunderte verschiedene Vorgehensweisen dafür, Updates auszuliefern. WinGet. Nuget (.NET). Klassische OS-Paketmanager oder Flathub/Snap (Linux), Eigene Infrastruktur und eigener Code (würde ich bevorzugen). Oder man leiht sich etwas, was ganz besonders Fancy sein soll, aus dem Mac Universum ... und brauchst am Ende trotzdem eine Infrastruktur. Denn du musst dich dann auch mit dem ominösen Appcast Feed auseinander setzen. Und dafür brauchst du dann auch wieder einen Server. Da scheint es kein zentrales Registry zu geben. Ich kenne mich damit auch nicht aus. Aber selber etwas zu basteln gibt einem volle Kontrolle über den Prozess und es lässt sich haarfein steuern. Und meiner Meinung nach sind XML-Files sowas von 2000.

Verfasst: **11.01.2026 10:36**

Man kann ja auch mit IsLibrary(#Library) zum Programmstart abfragen, ob die .DLL
geladen werden konnte und dann darauf reagieren. Das würde ich auf jeden Fall
machen, wenn ich mein Programm + DLL weitergebe. Und so eine DLL hat ja auch
Vorteile. Wenn sich der Aufruf der DLL-Funktion und deren Parameter nicht ändert
und evtl. nur ein Bug innerhalb der DLL-Funktion behoben werden muß, so reicht
dann auch nur der Austausch der .DLL.

Was ich noch sagen wollte : Da besteht ja gar kein so riesiger Unterschied zwischen einer .DLL und einer
statischen .LIB, was die Funktionen innerhalb dieser betrifft. Sowas hier gibt es ja auch :
https://www.binary-soft.com/dll2lib/dll2lib.htm

Verfasst: **11.01.2026 12:35**

Hallo Lieber H. Brill.

Das würde exakt meine Frage beantworten, ob dll oder lib bevorzugt würden.
Das über den Bereich Import sei dll oder lib muss ich mich wirklich wieder einlesen.

Sehr vieles ist in der Zwischenzeit vergessen gegangen.
Auffrischung tut gut, und würde meiner wagen Erinnerung entsprechen, dass
einige ältere Beiträge vorhanden sein müssen.

Recht herzlichen Dank und beste Grüße
Chris

H.Brill hat geschrieben: 11.01.2026 10:14
Das zumindest meine ursprüngliche Idee, wie wenn ich also beim Kompilieren mit IncludeBinary
auch die dll in der exe resp. dem ausführbaren programm mit kompiliere wäre das auch
die dll als separat vorhandene physische Datei nicht mehr erforderlich.
Als physisch vorhandene Datei muß sie sehr wohl beim Start deines Programmes
da sein. Nur schreibst du sie halt eben beim Start der .exe neu. Hat halt den
Vorteil, daß du sie nicht mehr separat mitliefern mußt.
Eine Ausnahme ist da MemoryModule, wo der Speicherbereich in dem binäre die DLL steckt,
direkt in den Speicher geladen wird. Das wurde dir aber auch schon im Jahre 2024 beantwortet.
Aber, wenn es schon mal eine statische .lib dafür gibt, würde ich diese bevorzugen.

Verfasst: **11.01.2026 13:04**

Hallo TroaX,

Es ist eine etwas schwierige Konstellation für den Kollegen die Anwendung zu erstellen.
Das zur Ausgangslage meiner Diskussionsstellung lib oder dll.

Die Überlegung war korrekt, dass auch so wenig wie möglich zusätzliche externe Daten betrifft begründet.
Eine eigene UpDate Routine bin ich im genannten Ur- Beitrag bereits am Aufbau gewesen,
dachte, ich könnte einige Elemente, sofern diese als lib in meine Anwendung zu implementieren möglich sind,
den Aufwand von einigen Elementen vereinfachen oder beschleunigen

Über den Sinn oder Unsinn lässt sich streiten, es geht zumal als Teile und noch nicht unbedingt die gesamte Technik zurzeit.

Die Überlegung, warum das Rad neu erfinden, wenn die Lokomotive bereits existiert. Oder so ähnlich...

Herzliche Grüsse
Chris

TroaX hat geschrieben: 11.01.2026 10:21 Vor allem weil es gerade um "Updates" geht, sollte man sich 5x überlegen, alles in die Executable zu schmeißen. Da bei Purebasic in der Regel immer mit dem aktuellen integrierten Stand der Libraries kompiliert wird, ist die Versionsnummer von Purebasic schon einmal ein wichtiges Indiz, ob die Exe geupdated werden muss oder nicht. Klar wenn man selber Änderungen am Code vorgenommen hat, muss die Exe auch aktualisiert werden. Wenn eine Library aktualisiert wurde, reicht es nur diese zu aktualisieren. Wenn man sie statisch in die Exe linkt bedeutet das, das die komplette Exe getauscht werden muss. Vor allem Libraries mit ständigen Updates sollten immer als DLL eingebunden werden. Hat man aber etwas grundlegendes, was sowieso immer mitgegeben und selten aktualisiert wird, kann man die Lib ins Programm direkt mit aufnehmen.

WinSparkle scheint das Tool für das Update mitzuliefern und ist komplett in der DLL enthalten. Wie du da auf Lib kommst, weiß ich nicht. Laut den Docs ist es eine "self-contained DLL" mit normaler Header Datei.
Code: Alles auswählen
#include <winsparkle.h>
Die DLL muss immer im Kontext anwesend sein. Das Programm "könnte" zwar starten (wenn man es später eingebunden hat). Aber warum man es dann überhaupt einbindet, verstehe ich nicht. Es soll sein Tool aktuell halten und das Werkzeug dazu würde man nicht mitliefern? So ganz verstehe ich deinen Gedankengang nicht. Das ist genauso wie "meine Kunden löschen die DLLs immer". Na und? Das ist kein Problem des Entwicklers! Software wird so ausgeliefert, wie sie entwickelt wurde. Wenn irgendeiner glaubt es besser zu wissen, dann ist seine eigene Dummheit auch sein eigenes Problem?!? o.O

Halte dich am besten einfach an die Docs. Da steht drin, wie man das machen muss. Und sieht auch sehr Einfach aus. Es gibt hunderte verschiedene Vorgehensweisen dafür, Updates auszuliefern. WinGet. Nuget (.NET). Klassische OS-Paketmanager oder Flathub/Snap (Linux), Eigene Infrastruktur und eigener Code (würde ich bevorzugen). Oder man leiht sich etwas, was ganz besonders Fancy sein soll, aus dem Mac Universum ... und brauchst am Ende trotzdem eine Infrastruktur. Denn du musst dich dann auch mit dem ominösen Appcast Feed auseinander setzen. Und dafür brauchst du dann auch wieder einen Server. Da scheint es kein zentrales Registry zu geben. Ich kenne mich damit auch nicht aus. Aber selber etwas zu basteln gibt einem volle Kontrolle über den Prozess und es lässt sich haarfein steuern. Und meiner Meinung nach sind XML-Files sowas von 2000.

Verfasst: **11.01.2026 13:43**

Naja, ich würde sagen : WinSparkle ist da etwas komfortabler.
Vielleicht bekommt man auch was mit den normalen FTP-Funktionen hin. Einen Webspace brauchst du ja
sowieso. Wenn man bspw. beim Start des Programms das Programm in einen temporären Ordner runter lädt und das Datum vergleicht.
Wenn das runtergeladene Programm neueren Datums ist, müßte man es entsprechend kopieren. Oder man schreibt sich ein entsprechendes
Tool, das in der Anwendung startet, das neue runterlädt, vergleicht und kopiert, die laufende Anwendung beendet und die neue Anwendung
wieder startet.
Ist nur mal so ein Gedanke von mir.

Verfasst: **17.01.2026 04:19**

Hallo und einen wunderschönen guten Samstagmorgen,

Da ich etwas Faul bin, was das selber suchen betrifft, habe ich versucht eine Anwendung zu erstellen,
die mir die Funktionen aus einer lib heraussucht.

Da es bei den dll anscheinend funktioniert, PellesC hab ich da sehr viel gefunden
aber bei der lib bekomme ich bis jetzt immer nur die obj Files. Ich machte mir
Gedanken dass doch sowas möglich sein müsste.

Diverse versuche auch CMD haben mich noch nicht zu Ziel geführt.
So habe ich mich begonnen wieder mit PB zu beschäftigen, ob es da nicht möglich wäre.

Versuch 4 oder 5 mit einer GUI nun hier wo ich vorerst nur die lib öffnen möchte.
Ja es gib einen dll zu lib auf kommerzieller Basis bei dem ich aber bei diversen 64 Bit dll
in der Demo immer wieder Abstürze der Anwendung verursachte.

Zudem die Software ca. 100 US$ kostet, was ich nicht gerade lustig finde,
wenn mir dann andauernd abstürze der Anwendung unter die Augen kommen.

OK, mein neuster Versuch bricht auch mit einer Error Meldung ab und genau da
möchte ich Euch etwas um Rate Fragen.

Beim Eröffnung Teil wo ich gerne die lib untersuchen möchte erhalte ich eine Speicherverletzung Meldung.
Import lib habe ich jetzt nicht verwendet da ich nicht sicher war, ob die Funktion, die mich interessiert klappt.

ExamineLibraryFunctions()

Aber genau diese erzeugt mir jetzt beim Öffnen einen Error.
Verzeiht meinen sehr rudimentären Code, den ich hier zusammen gefrickelt habe auch 4 diversen versuch der GUI.
Ich versuche das gesamte dann auch noch etwas besser zu gestalten, sodass auch mehr Informationen zu den Elementteilen
gegeben sind die etwas mehr erklärend wirken.

Open Library funktioniert diese nicht mit lib, sondern nur mit dll ?
Resp. ExamineLibraryFunctions() funktioniert diese nur mit dll und nicht mit lib Datei,
das wären so meine beiden Fragezeichen, die ich zurzeit habe, warum es zu einer Speicherverletzung kommen könnte.

Ich hoffe, ich habe dieses Mal nicht bereits wieder einen Gedanken Fehler begangen.

Herzliche Grüße und beste Wünsche für das Wochenende.

Code: Alles auswählen

;- Top
; -----------------------------------------------------------------------------
;           Name:
;    Description:
;         Author:
;           Date: 2026-01-17
;        Version:
;     PB-Version:
;             OS:
;         Credit:
;          Forum:
;     Created by: csc
; -----------------------------------------------------------------------------

CompilerIf #PB_Compiler_IsMainFile
  EnableExplicit
CompilerEndIf

;- Global
Global Window_0
Global MainMenu
Global ToolBar
Global StatusBar

Global Combo_1, Cont_1, ListIcon_1

Global File$

;- Lade Bilder
UsePNGImageDecoder()

;- Declare
Declare Event_Cont_1()
Declare Menu_Window_0()
Declare ToolBar_Window_0()
Declare StatusBar_Window_0()

  DataSection
    ToolBarIcon_New:  			: IncludeBinary #PB_Compiler_Home + "examples/sources/Data/ToolBar/New.png"
    ToolBarIcon_Open: 			: IncludeBinary #PB_Compiler_Home + "examples/sources/Data/ToolBar/Open.png"
    ToolBarIcon_Save: 			: IncludeBinary #PB_Compiler_Home + "examples/sources/Data/ToolBar/Save.png"
    ToolBarIcon_Properties: : IncludeBinary #PB_Compiler_Home + "examples/sources/Data/ToolBar/Properties.png"
    ToolBarIcon_Help1: 			: IncludeBinary #PB_Compiler_Home + "examples/sources/Data/ToolBar/Help.png"
    ToolBarIcon_Help2: 			: IncludeBinary #PB_Compiler_Home + "examples/sources/Data/ToolBar/Help.png"
  EndDataSection
  
  
Procedure StatusBar_Window_0()
  StatusBar = CreateStatusBar(#PB_Any, WindowID(Window_0))
  If StatusBar
    AddStatusBarField(120)
    AddStatusBarField(150)
    AddStatusBarField(#PB_Ignore)
    StatusBarText(StatusBar, 0, "Statusleiste")
    StatusBarText(StatusBar, 1, "Zentrum", #PB_StatusBar_BorderLess | #PB_StatusBar_Center)
    StatusBarText(StatusBar, 2, "Rechts", #PB_StatusBar_Right | #PB_StatusBar_Raised)
  EndIf
EndProcedure

Procedure Menu_Window_0()
  MainMenu = CreateMenu(#PB_Any, WindowID(Window_0))
  If MainMenu
    MenuTitle("Datei")
    MenuItem(1, "Öffnen...")
    MenuItem(2, "Speichern")
    MenuBar()
    MenuItem(3, "&Beenden")
    MenuTitle("?")
    MenuItem(4, "Über")
  EndIf
EndProcedure


Procedure ToolBar_Window_0()
  Protected Image
  ToolBar = CreateToolBar(#PB_Any, WindowID(Window_0), #PB_ToolBar_Large | #PB_ToolBar_Text)
  If ToolBar
    Image = CatchImage(#PB_Any, ?ToolBarIcon_Open)
    ToolBarImageButton(1, ImageID(Image), #PB_ToolBar_Normal, "Öffnen...")
    FreeImage(Image)
    Image = CatchImage(#PB_Any, ?ToolBarIcon_Save)
    ToolBarImageButton(2, ImageID(Image), #PB_ToolBar_Normal, "Speichern")
    FreeImage(Image)
    ToolBarSeparator()
  EndIf
 EndProcedure
 
  Procedure Open_Window_0(X = 0, Y = 0, Width = 870, Height = 470)
  Window_0 = OpenWindow(#PB_Any, X, Y, Width, Height, "Title", #PB_Window_SystemMenu | #PB_Window_MaximizeGadget | #PB_Window_SizeGadget | #PB_Window_TitleBar | #PB_Window_ScreenCentered)
  If Window_0

    Menu_Window_0()
    ToolBar_Window_0()
    StatusBar_Window_0()

    ListIcon_1 = ListIconGadget(#PB_Any, 0, 52, 870, 320, "Funktions Name", 120, #PB_ListIcon_CheckBoxes | #PB_ListIcon_ThreeState | #PB_ListIcon_GridLines | #PB_ListIcon_FullRowSelect | #PB_ListIcon_HeaderDragDrop)
      AddGadgetColumn(ListIcon_1, 1, "Parameter", 100)
      AddGadgetColumn(ListIcon_1, 2, "Variable", 100)
      AddGadgetColumn(ListIcon_1, 3, "Prozedur", 50)
      AddGadgetColumn(ListIcon_1, 4, "Komentare", 50)
      
      AddGadgetItem(ListIcon_1, -1, "ListIcon_1")
      
    Cont_1 = ContainerGadget(#PB_Any, 0, 372, 870, 50, #PB_Container_Raised)
      Combo_1 = ComboBoxGadget(#PB_Any, 0, 10, 170, 24)
        AddGadgetItem(Combo_1, -1, "STDCALL")
        AddGadgetItem(Combo_1, -1, "CDECL")
        AddGadgetItem(Combo_1, -1, "FASTCALL")        
;        SetGadgetState(Combo_1, 0)
;     CloseGadgetList()   ; Cont_1        
;    CloseGadgetList()   ; Cont_1

;    BindGadgetEvent(Cont_1, @Event_Cont_1())
    PostEvent(#PB_Event_SizeWindow, Window_0, 0)
    ProcedureReturn #True
  EndIf
EndProcedure


CompilerIf #PB_Compiler_IsMainFile
;- Hauptprogramm
If Open_Window_0()
 
  ;IceKeepEventLoop
  Repeat
    Select WaitWindowEvent()
      Case #PB_Event_CloseWindow
        Break

        ;-> Event Menu
      Case #PB_Event_Menu
        Select EventMenu()
        
          Case 1   ;Open
             File$ = OpenFileRequester("Library - Open", "Pure.lib", "Library (*.lib)|*.lib", 0)
             If File$+File$
              MessageRequester("Information", "Selected File: "+File$, 0);
              
              OpenLibrary(#PB_Any,"File$")
              IsLibrary(#PB_Any)
               ExamineLibraryFunctions(#PB_Any)
    				EndIf
    				
          Case 3   ;Quit
            Break
          Default
;            MessageRequester("Information", "ToolBar oder Menu ID : " + Str(EventMenu()) +#CRLF$+#CRLF$+ "Text : " + GetMenuItemText(MainMenu, EventMenu()), 0)
        EndSelect

        ;-> Event Gadget
      Case #PB_Event_Gadget
        Select EventGadget()
        EndSelect

    EndSelect
  ForEver
  ;EndIceKeepEventLoop
EndIf
CompilerEndIf
CloseLibrary(#PB_All)

PureBoard

FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?

Re: FRAGE: Arbeitsaufwand verwendung dll oder lib v(WIN) ?