Windows library more than twice the size compared to Linux?

[Mijikai]

I recently started cross-platform development on Linux and created a simple 2D library
that only uses these functions: malloc(), calloc(), memset(), memcpy(), free()
(PureBasic 6.12 x64 LTS)

When i compile the library on Windows it is more than twice the size !?
Why is it so big, i only use simple C functions ?

If i look into it, i see many embedded strings that make no sense:

0001C790 4A 61 6E 75 61 72 79 00 54 68 75 72 73 64 61 79 January.Thursday
0001C7A0 00 00 00 00 00 00 00 00 54 75 65 73 64 61 79 00 ........Tuesday.
0001C7B0 57 65 64 6E 65 73 64 61 79 00 00 00 00 00 00 00 Wednesday.......
0001C7C0 53 61 74 75 72 64 61 79 00 00 00 00 00 00 00 00 Saturday........
0001C7D0 47 65 74 44 61 74 65 46 6F 72 6D 61 74 45 78 00 GetDateFormatEx.
0001C7E0 47 65 74 54 69 6D 65 46 6F 72 6D 61 74 45 78 00 GetTimeFormatEx.
0001C7F0 45 6E 75 6D 53 79 73 74 65 6D 4C 6F 63 61 6C 65 EnumSystemLocale
0001C800 73 45 78 00 00 00 00 00 47 65 74 4C 6F 63 61 6C sEx.....GetLocal
0001C810 65 49 6E 66 6F 45 78 00 49 6E 69 74 69 61 6C 69 eInfoEx.Initiali
0001C820 7A 65 43 72 69 74 69 63 61 6C 53 65 63 74 69 6F zeCriticalSectio
0001C830 6E 45 78 00 00 00 00 00 4C 43 4D 61 70 53 74 72 nEx.....LCMapStr
0001C840 69 6E 67 45 78 00 00 00 43 6F 6D 70 61 72 65 53 ingEx...CompareS
0001C850 74 72 69 6E 67 45 78 00 6F 70 65 72 61 74 6F 72 tringEx.operator
0001C860 20 63 6F 5F 61 77 61 69 74 00 00 00 00 00 00 00 co_await.......
0001C870 5F 5F 72 65 73 74 72 69 63 74 00 00 00 00 00 00 __restrict......
0001C880 43 6F 72 45 78 69 74 50 72 6F 63 65 73 73 00 00 CorExitProcess..
0001C890 48 48 3A 6D 6D 3A 73 73 00 00 00 00 00 00 00 00 HH:mm:ss........
0001C8A0 6F 70 65 72 61 74 6F 72 00 00 00 00 00 00 00 00 operator........
0001C8B0 4F 63 74 6F 62 65 72 00 4E 6F 76 65 6D 62 65 72 October.November
0001C8C0 00 00 00 00 00 00 00 00 53 65 70 74 65 6D 62 65 ........Septembe
0001C8D0 72 00 00 00 00 00 00 00 44 65 63 65 6D 62 65 72 r.......December
0001C8E0 00 00 00 00 00 00 00 00 55 6E 6B 6E 6F 77 6E 20 ........Unknown
0001C8F0 65 78 63 65 70 74 69 6F 6E 00 00 00 00 00 00 00 exception.......
0001C900 62 61 64 20 65 78 63 65 70 74 69 6F 6E 00 00 00 bad exception...
0001C910 5F 5F 66 61 73 74 63 61 6C 6C 00 00 00 00 00 00 __fastcall......
0001C920 5F 5F 74 68 69 73 63 61 6C 6C 00 00 00 00 00 00 __thiscall......
0001C930 5F 5F 76 65 63 74 6F 72 63 61 6C 6C 00 00 00 00 __vectorcall....
0001C940 5F 5F 63 6C 72 63 61 6C 6C 00 00 00 00 00 00 00 __clrcall.......
0001C950 5F 5F 73 74 64 63 61 6C 6C 00 00 00 00 00 00 00 __stdcall.......
0001C960 5F 5F 63 64 65 63 6C 00 5F 5F 70 61 73 63 61 6C __cdecl.__pascal

Or:

0001E5A0 73 00 70 00 61 00 6E 00 69 00 73 00 68 00 2D 00 s.p.a.n.i.s.h.-.
0001E5B0 76 00 65 00 6E 00 65 00 7A 00 75 00 65 00 6C 00 v.e.n.e.z.u.e.l.
0001E5C0 61 00 00 00 00 00 00 00 73 00 70 00 61 00 6E 00 a.......s.p.a.n.
0001E5D0 69 00 73 00 68 00 2D 00 67 00 75 00 61 00 74 00 i.s.h.-.g.u.a.t.
0001E5E0 65 00 6D 00 61 00 6C 00 61 00 00 00 00 00 00 00 e.m.a.l.a.......
0001E5F0 73 00 70 00 61 00 6E 00 69 00 73 00 68 00 2D 00 s.p.a.n.i.s.h.-.
0001E600 62 00 6F 00 6C 00 69 00 76 00 69 00 61 00 00 00 b.o.l.i.v.i.a...
0001E610 73 00 70 00 61 00 6E 00 69 00 73 00 68 00 2D 00 s.p.a.n.i.s.h.-.
0001E620 63 00 6F 00 6C 00 6F 00 6D 00 62 00 69 00 61 00 c.o.l.o.m.b.i.a.
0001E630 00 00 00 00 00 00 00 00 73 00 6F 00 75 00 74 00 ........s.o.u.t.
0001E640 68 00 2D 00 6B 00 6F 00 72 00 65 00 61 00 00 00 h.-.k.o.r.e.a...
0001E650 73 00 6F 00 75 00 74 00 68 00 20 00 6B 00 6F 00 s.o.u.t.h. .k.o.
0001E660 72 00 65 00 61 00 00 00 73 00 6F 00 75 00 74 00 r.e.a...s.o.u.t.
0001E670 68 00 2D 00 61 00 66 00 72 00 69 00 63 00 61 00 h.-.a.f.r.i.c.a.

What is this trash?

[DarkDragon]

Locale information, probably from some standard library. No trash. Windows doesn't like sharing libraries, linux shares everything possible. Two paradigms, although some users like Flatpaks and AppImages and so on.

[Fred]

The C runtime is statically linked on Windows, while it's dynamically linked on linux.