Does PureBasic load GDIPLUS library without reason ?

[pamen]

@Olli
Does PureBasic load GDIPLUS library without reason ?
On Windows obviously.

[Kuron]

Unless you are targeting an OS older than XP where GDI+ doesn't exist, I am not understanding the issue. PB has a plethora of third-party libs. The chances of some of them using GDI+ is pretty good.

[Olli]

@kuron

Thank you for the answer. It seems, for pamen, a conflict occurs between GDIPLUS and an other external library pack (final product).

But I am puzzled by a default automatic load of GDIPLUS.

So, from one question, other questions bear.

-1> Since which version ?
-2> What equivalent on Linux and MacOsX ?
-3> Which solving way is possible ?

(for the 3rd question, I suppose a root pipe console, but it maybe seems an other way is doable)

[Fred]

We use GDIPlus for a various topics, it's pretty much a core library for PureBasic like kernel32

[pamen]

It would be great to have it on the first page in the Help file (something like the below),
so users like pamen are not bugging the forum and wasting people's time.

General Topics

Using the command line compiler
General Syntax Rules
Variables, Types and Operators
Compiled Executable Behavior (differences from C, ASM, C++)

[Kuron]

@Olli I have not looked at the source for the IDE, but I would imagine the IDE itself uses GDI+ along with most image/graphic/GUI commands to some extent.

Sounds like the issue is the external third-party lib Pamen is trying to use (from what you have said). Pamen might need to talk to the developer of the third-party lib, as PB certainly should not be expected to be crippled to meet the needs of any third-party lib (of which there are thousands). PB is simply not going to be compatible with every lib on the 'Net, nor should it be expected to.

Simply put, PB using GDI+ isn't the issue. PB is working as it is supposed to.

The bigger issue is why in the hell is a C++ subclassing lib loading GDI+? GDI+ should not be needed for that purpose, unless there is an unfixed exploit in GDI+ this subclassing lib is trying to target for nefarious purposes.

[idle]

If it's a skinning lib maybe it's patching a gdi+ function or functions.

[User_Russian]

Does PureBasic load GDIPLUS library without reason ?

Used since version 4.40 when the VectorDrawing library was added.

[pamen]

For reference:
these are loaded in a UI application with no WEBGadget, only standard controls and CommCtrl gadgets:
Obviously they will depend on Switches like "ModernUI" = uxtheme.dll and so on.
Windows itself will load dependent libs obviously.
Same thing for 64 and 32 GUI apps

'PureBasicWin64App.exe' ntdll.dll'. Symbols loaded.
'PureBasicWin64App.exe' kernel32.dll'. Symbols loaded.
'PureBasicWin64App.exe' KernelBase.dll'. Symbols loaded.
'PureBasicWin64App.exe' msvcrt.dll'.
'PureBasicWin64App.exe' ole32.dll'.
'PureBasicWin64App.exe' msvcp_win.dll'.
'PureBasicWin64App.exe' ucrtbase.dll'.
'PureBasicWin64App.exe' gdi32.dll'.
'PureBasicWin64App.exe' win32u.dll'.
'PureBasicWin64App.exe' gdi32full.dll'. Symbols loaded.
'PureBasicWin64App.exe' user32.dll'. Symbols loaded.
'PureBasicWin64App.exe' combase.dll'.
'PureBasicWin64App.exe' rpcrt4.dll'.
'PureBasicWin64App.exe' winmm.dll'.
'PureBasicWin64App.exe' (Win32): Loaded 'C:\Windows\WinSxS\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.22000.2003_none_4c4fc4c1c574dc79\GdiPlus.dll'. Symbols loaded.
'PureBasicWin64App.exe' (Win32): Loaded 'C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.22000.120_none_9d947278b86cc467\comctl32.dll'. Symbols loaded.
'PureBasicWin64App.exe' imm32.dll'.
'PureBasicWin64App.exe' msimg32.dll'.
'PureBasicWin64App.exe' uxtheme.dll'. Symbols loaded.
'PureBasicWin64App.exe' (Win32): Unloaded 'C:\Windows\System32\uxtheme.dll'
'PureBasicWin64App.exe' uxtheme.dll'. Symbols loaded.
'PureBasicWin64App.exe' msctf.dll'.
'PureBasicWin64App.exe' kernel.appcore.dll'.
'PureBasicWin64App.exe' bcryptprimitives.dll'.
'PureBasicWin64App.exe' vcruntime140_1d.dll'.
'PureBasicWin64App.exe' vcruntime140d.dll'.
'PureBasicWin64App.exe' msvcp140d.dll'.
'PureBasicWin64App.exe' ucrtbased.dll'.
'PureBasicWin64App.exe' dwmapi.dll'.
'PureBasicWin64App.exe' sechost.dll'.
'PureBasicWin64App.exe' TextInputFramework.dll'.
'PureBasicWin64App.exe' oleaut32.dll'.
'PureBasicWin64App.exe' CoreMessaging.dll'.
'PureBasicWin64App.exe' CoreUIComponents.dll'.
'PureBasicWin64App.exe' WinTypes.dll'.
'PureBasicWin64App.exe' advapi32.dll'.
'PureBasicWin64App.exe' cryptbase.dll'.
'PureBasicWin64App.exe' TextShaping.dll'.
'PureBasicWin64App.exe' shlwapi.dll'.
'PureBasicWin64App.exe' SHCore.dll'.
'PureBasicWin64App.exe' WindowsCodecs.dll'.
'PureBasicWin64App.exe' DWrite.dll'.

[Olli]

I understand your worry, Pamela. But if you work on the compiler console mode, what is the real list in this way ?

Code: Select all

openconsole()
printn("Compile me on console mode in the compiler options.")
printn("Press [Return] to quit...")
input()

[Fred]

This list doesn't reflect what PB executables are using, if you want to see it you can use this new dependency walker: https://github.com/lucasg/Dependencies . A standard PB GUI program uses very few libs:

Code: Select all

msvcrt.dll
kernel32.dll
ole32.dll
gdiplus.dll
user32.dll
gdi32.dll
comctl32.dll

Which are very small requirement are all these are standard libs available without installing anything on any Windows starting from XP. That's why PB executables are not subject to "DLL hell" or anything and run anywhere.

[pamen]

Perfect, thank you Fred!
So that is all we all need to know.