On Thu, 10 Aug 2023 10:12:47 -0700, Michael S wrote:

> On Thursday, August 10, 2023 at 7:59:25 PM UTC+3, Scott Lurndal wrote:
>> Kaz Kylheku <864-11...@kylheku.com> writes:
>> >On 2023-08-10, Scott Lurndal <sc...@slp53.sl.home> wrote:
>> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> >>>sc...@slp53.sl.home (Scott Lurndal) writes:
>> >>>
>> >>>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> >>>>>Bart <b...@freeuk.com> writes:
>> >>>>
>> >>>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>> >>>>>> just a fact.
>> >>>>>
>> >>>>>2+2 = 4. That's just a fact.
>> >>>>
>> >>>> Indeed, and it is a fact for _any_ library containing optional functionality
>> >>>> that is needed by the application.
>> >>>
>> >>>That's only true in a circular way. Why are the math functions
>> >>>considered optional? Why not, for example, consider the IO functions
>> >>>optional so that any program that includes <stdio.h> has to link with
>> >>>-lio? (I know the history -- that's not what I'm asking.)
>> >>>
>> >>>There's even a division that could be justified by the standard. Any
>> >>>program that uses functions not required in a freestanding
>> >>>implementation could be obliged to link with -lhosted, but requiring -lm
>> >>>is just a historical barnacle.
>> >>
>> >> Yes, it's historical, and an artifact of small memory systems and
>> >> archive libraries.
>> >>
>> >> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
>> >> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
>> >> driver (cc)?
>> >
>> >This is entirely feasible, technologically.
>> >
>> >As a pretty simple hack, header files for these libraries could
>> >declare the "soname" that is required to call their functions.
>> >
>> >The compiler would attach that to the declarations made in those
>> >headers and then if any of those symbols are referenced, append
>> >the -l<soname> to the linker line.
>> >
>> >In the Microsoft Visual C/C++ world, a source file can indicate that it
>> >needs a particular DLL, so that it doesn't have to be specified on the
>> >command line.
>> Ah, yes. DLL hell. Something that has not yet been an issue for
>> unix/linux, and hopefully never will.
>
> In my personal experience DLL hell on Linux is innumerably worse
> than it ever was on Windows.
> On Windows, at worst one can put needed versions of DLLs in the
> same directory with exe and things will work.
> On Linux, I found no ways short of static link to cause binaries compiled
> on newer Debian to run on LTS variant of Ubuntu. And that's with Debian
> and Ununtu, two distros that are rather close relatives. I wonder what is
> going to happen if try unrelated distros.

Then, I've got to say, "You are doing it wrong."
But, as this is comp.lang.c and not comp.unix.programmer, I won't elaborate
on my comment here.
--
Lew Pitcher
"In Skills We Trust"

On Thursday, August 10, 2023 at 8:16:31 PM UTC+3, Lew Pitcher wrote:
> On Thu, 10 Aug 2023 10:12:47 -0700, Michael S wrote:
>
> > On Thursday, August 10, 2023 at 7:59:25 PM UTC+3, Scott Lurndal wrote:
> >> Kaz Kylheku <864-11...@kylheku.com> writes:
> >> >On 2023-08-10, Scott Lurndal <sc...@slp53.sl.home> wrote:
> >> >> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >> >>>sc...@slp53.sl.home (Scott Lurndal) writes:
> >> >>>
> >> >>>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >> >>>>>Bart <b...@freeuk.com> writes:
> >> >>>>
> >> >>>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
> >> >>>>>> just a fact.
> >> >>>>>
> >> >>>>>2+2 = 4. That's just a fact.
> >> >>>>
> >> >>>> Indeed, and it is a fact for _any_ library containing optional functionality
> >> >>>> that is needed by the application.
> >> >>>
> >> >>>That's only true in a circular way. Why are the math functions
> >> >>>considered optional? Why not, for example, consider the IO functions
> >> >>>optional so that any program that includes <stdio.h> has to link with
> >> >>>-lio? (I know the history -- that's not what I'm asking.)
> >> >>>
> >> >>>There's even a division that could be justified by the standard. Any
> >> >>>program that uses functions not required in a freestanding
> >> >>>implementation could be obliged to link with -lhosted, but requiring -lm
> >> >>>is just a historical barnacle.
> >> >>
> >> >> Yes, it's historical, and an artifact of small memory systems and
> >> >> archive libraries.
> >> >>
> >> >> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
> >> >> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
> >> >> driver (cc)?
> >> >
> >> >This is entirely feasible, technologically.
> >> >
> >> >As a pretty simple hack, header files for these libraries could
> >> >declare the "soname" that is required to call their functions.
> >> >
> >> >The compiler would attach that to the declarations made in those
> >> >headers and then if any of those symbols are referenced, append
> >> >the -l<soname> to the linker line.
> >> >
> >> >In the Microsoft Visual C/C++ world, a source file can indicate that it
> >> >needs a particular DLL, so that it doesn't have to be specified on the
> >> >command line.
> >> Ah, yes. DLL hell. Something that has not yet been an issue for
> >> unix/linux, and hopefully never will.
> >
> > In my personal experience DLL hell on Linux is innumerably worse
> > than it ever was on Windows.
> > On Windows, at worst one can put needed versions of DLLs in the
> > same directory with exe and things will work.
> > On Linux, I found no ways short of static link to cause binaries compiled
> > on newer Debian to run on LTS variant of Ubuntu. And that's with Debian
> > and Ununtu, two distros that are rather close relatives. I wonder what is
> > going to happen if try unrelated distros.
> Then, I've got to say, "You are doing it wrong."

That's possible. But discovering how to do it right is certainly not easy.

> But, as this is comp.lang.c and not comp.unix.programmer, I won't elaborate
> on my comment here.

I'd just say that if Gnu/Linux was not a mess then people would not need to
invent containers etc. And VMs will be far less popular.
And I feel like shared libraries are very big part of the mess.
On the other hand, the Linux proper, the kernel, is likely the least problematic.

> --
> Lew Pitcher
> "In Skills We Trust"

Michael S <already5chosen@yahoo.com> writes:
>On Thursday, August 10, 2023 at 8:16:31=E2=80=AFPM UTC+3, Lew Pitcher wrote=
>:

>> But, as this is comp.lang.c and not comp.unix.programmer, I won't elabora=
>te=20
>> on my comment here.=20
>
>I'd just say that if Gnu/Linux was not a mess then people would not need to
>invent containers etc.

Say what? Containers are there for easy deployment and primarily
for security sandboxing, not because of some soi disant linux 'dll hell'.

>And I feel like shared libraries are very big part of the mess.

Feelings aren't reality.

On 8/10/2023 9:59 AM, Lew Pitcher wrote:
> On Thu, 10 Aug 2023 16:31:31 +0000, Kaz Kylheku wrote:
>
>> On 2023-08-10, Vir Campestris <vir.campestris@invalid.invalid> wrote:
>>> On 07/08/2023 17:05, Ben Bacarisse wrote:
>>>> Hmm... With statically allocated strings, or using malloc and therefore
>>>> requiring free call not shown?
>>>>
>>>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>>>> macro:
>>>>
>>>> typedef float salary_t;
>>>> #define FMT_SALARY "f"
>>>>
>>>> typedef unsigned long int payrollid_t;
>>>> #define FMT_PAYROLLID "lu"
>>>>
>>>> so that one can write
>>>>
>>>> printf("Hello %s your salary is %" FMT_SALLARY
>>>> ", your payrollid %" FMT_PAYROLLID "\n",
>>>> employee.name, employee.salary, employee.payrollid);
>>>>
>>>> -- Ben.
>>>
>>> Ben, if you put floating points in money accountants get upset.
>>>
>>> Three employees are paid $100.00, so it adds up to $300.
>>>
>>> Deduct $20 from each, and it's $240.
>>>
>>> Use floating point and sooner or later it won't add up.
>>
>> Use floating-point *naively* and the truncation errors will accumulate
>> to the point of making at least a one cent difference, screwing up the
>> accounting.
>>
>> Use floating-point intelligently and that won't happen.
>>
>>> You can't have a third of a cent.
>>
>> That is neither here nor there.
>>
>> You can't have a third of a cent in accounting, because accounting is
>> decimal based, at least with US dollars and similar currencies,
>> where you don't have beasties like sixths of a dollar.
>
> Actually, many currencies (including the US Dollar) allow for measurements
> in the thousandths of a dollar, and such calculations are common in both
> stock brokerage pricing (a broker may charge, say, 5 mils per share on
> bulk trades, earning $5.00 for every 1000 shares bought/sold) and property
> tax calculation.
>
>> "Third of a cent" is a financial quantity nobody works with, in any
>> representation of dollars.
>
> Except for those who work with money as a commodity, stock brokers,
> municipal property tax assessors, and a wide variety of others. Consider,
> at this moment, I see that 1 Japanese Yen will buy 0.0069 US Dollars.
> How inconvenient would it be if programmers just took the position that
> there are no fractions of a US dollar lower than 1 cent, and that 1 Yen,
> therefore, purchases $0.00 USD?
>
>> And even if they did, floating point
>> could handle it just fine, if everyone agreed that around 15
>> digits of precision is good enough.
>
> For very small and very large sums of money, most banking systems
> will stay /very/ far away from floatingpoint in any form. Better
> to do (expensive) fixed-precision math and get exact answers than
> to do (cheaper) floatingpoint math and get the final /financial/
> answer wrong. That's how banks fail, and programmers get rich
> from rounding errors (watch the movie "Office Space").

Or SuperMan 3... ;^)

On 2023-08-10, Scott Lurndal <scott@slp53.sl.home> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>On 2023-08-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>>Bart <bc@freeuk.com> writes:
>>>>>
>>>>>>> If working with Linux and you need -lm, then 'make prog' won't work. That's
>>>>>>> just a fact.
>>>>>>
>>>>>>2+2 = 4. That's just a fact.
>>>>>
>>>>> Indeed, and it is a fact for _any_ library containing optional functionality
>>>>> that is needed by the application.
>>>>
>>>>That's only true in a circular way. Why are the math functions
>>>>considered optional? Why not, for example, consider the IO functions
>>>>optional so that any program that includes <stdio.h> has to link with
>>>>-lio? (I know the history -- that's not what I'm asking.)
>>>>
>>>>There's even a division that could be justified by the standard. Any
>>>>program that uses functions not required in a freestanding
>>>>implementation could be obliged to link with -lhosted, but requiring -lm
>>>>is just a historical barnacle.
>>>
>>> Yes, it's historical, and an artifact of small memory systems and
>>> archive libraries.
>>>
>>> None the less, would you also expect that -lopenssl, -lncurses, -lpthread,
>>> -ldl, -lrt, -lz, etc. should also be automatically appended by the compiler
>>> driver (cc)?
>>
>>This is entirely feasible, technologically.
>>
>>As a pretty simple hack, header files for these libraries could
>>declare the "soname" that is required to call their functions.
>>
>>The compiler would attach that to the declarations made in those
>>headers and then if any of those symbols are referenced, append
>>the -l<soname> to the linker line.
>>
>>In the Microsoft Visual C/C++ world, a source file can indicate that it
>>needs a particular DLL, so that it doesn't have to be specified on the
>>command line.
>
> Ah, yes. DLL hell. Something that has not yet been an issue for
> unix/linux, and hopefully never will.

While DLLs have some issues, there are some aspects of DLL's that
are better than shared libraries on Linux.

The Unix people hit on a good idea in their C language implementation:
that when a file contains an #include "..." directive, where the
.... is a relative path name, it is resolved relative to the directory
of that file which is invoking #include syntax is found.

Windows does a similar thing for DLL's. A program can be shipped
with its DLLs, which are easily found because they are in the
same directory.

This would be a huge improvement for shared libs. It's incredible
that the developers of the ELF stuff didn't notice how
nice #include is. Nobody every has to set a weird enviornment
variable to get "foo.c" to find "foo.h".

DLLs are lacking in some technology like symbol versioning, linking
in any direction (DLL cannot attach to symbols exported by executable)
and such. Plus the use of clunky .lib files taht SO's don't require,
and __decl(dllexport) and other cruft. (That pragma mechanism by
which a source file indicates a needed DLL doesn't need a .lib file
though, IIRC).

"DLL hell", I think referred to the historic situation whereby programs
on Windows, were neglecting to take advantage of the ability to find
their own libs in the same directory, but stupidly installing DLLs in
the system folder. If that is done for some popular run-time DLL,
like a MSVC redistributable run-time, then that caused problems
because there were different version of it under a different name.

If you install your .EXE and .DLL files in one directory, there is no
"DLL Hell".

And Microsoft has a much better backwards compatibility track record
in their system DLL's like user32.dll and kernel32.dll, than pretty much
any FOSS environment.

Windows programs from the 1990's still have a good chance of running on
new Windows, even though they need DLLs.

Linux? LOL. Maybe something statically linked. Or not? (The "a.out"
executable format has been removed, right?)

In the 1990'ws, Linux had shared libraries that were made by
disassembling code, and using text editing. The libraries were not
relocatable: they were globally assigned addresses. Nothing from that
era will run today.

Only a few core libraries in the Linux ELF world actually do proper
versioning. Some just issue a new version whenever they make a breaking
change, and if that is not installed, old binaries cannot run.

But that's okay, because you just get newly recompiled everything
from your mother ship distro.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-10, Scott Lurndal <scott@slp53.sl.home> wrote:
> Michael S <already5chosen@yahoo.com> writes:
>>On Thursday, August 10, 2023 at 8:16:31=E2=80=AFPM UTC+3, Lew Pitcher wrote=
>>:
>
>>> But, as this is comp.lang.c and not comp.unix.programmer, I won't elabora=
>>te=20
>>> on my comment here.=20
>>
>>I'd just say that if Gnu/Linux was not a mess then people would not need to
>>invent containers etc.
>
> Say what? Containers are there for easy deployment and primarily
> for security sandboxing, not because of some soi disant linux 'dll hell'.

Is there a big difference between "not easy deployment" and "dll hell"?

Containers replace shared library hell with container hell.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-10, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Thu, 10 Aug 2023 16:31:31 +0000, Kaz Kylheku wrote:
>
>> On 2023-08-10, Vir Campestris <vir.campestris@invalid.invalid> wrote:
>>> On 07/08/2023 17:05, Ben Bacarisse wrote:
>>>> Hmm... With statically allocated strings, or using malloc and therefore
>>>> requiring free call not shown?
>>>>
>>>> I would rather do this: anywhere a type is defined, I'd define a FMT_xxx
>>>> macro:
>>>>
>>>> typedef float salary_t;
>>>> #define FMT_SALARY "f"
>>>>
>>>> typedef unsigned long int payrollid_t;
>>>> #define FMT_PAYROLLID "lu"
>>>>
>>>> so that one can write
>>>>
>>>> printf("Hello %s your salary is %" FMT_SALLARY
>>>> ", your payrollid %" FMT_PAYROLLID "\n",
>>>> employee.name, employee.salary, employee.payrollid);
>>>>
>>>> -- Ben.
>>>
>>> Ben, if you put floating points in money accountants get upset.
>>>
>>> Three employees are paid $100.00, so it adds up to $300.
>>>
>>> Deduct $20 from each, and it's $240.
>>>
>>> Use floating point and sooner or later it won't add up.
>>
>> Use floating-point *naively* and the truncation errors will accumulate
>> to the point of making at least a one cent difference, screwing up the
>> accounting.
>>
>> Use floating-point intelligently and that won't happen.
>>
>>> You can't have a third of a cent.
>>
>> That is neither here nor there.
>>
>> You can't have a third of a cent in accounting, because accounting is
>> decimal based, at least with US dollars and similar currencies,
>> where you don't have beasties like sixths of a dollar.
>
> Actually, many currencies (including the US Dollar) allow for measurements
> in the thousandths of a dollar, and such calculations are common in both
> stock brokerage pricing (a broker may charge, say, 5 mils per share on
> bulk trades, earning $5.00 for every 1000 shares bought/sold) and property
> tax calculation.
>
>> "Third of a cent" is a financial quantity nobody works with, in any
>> representation of dollars.
>
> Except for those who work with money as a commodity, stock brokers,
> municipal property tax assessors, and a wide variety of others. Consider,
> at this moment, I see that 1 Japanese Yen will buy 0.0069 US Dollars.
> How inconvenient would it be if programmers just took the position that
> there are no fractions of a US dollar lower than 1 cent, and that 1 Yen,
> therefore, purchases $0.00 USD?

BUt that isn't 1/3; it is 69/10000, representing a decimal value that
has been truncated to 4 digits.

It has two significant figures in it. IEEE double has 13 more
to approximate it.

..0069 in IEEE double is actually 0.00689999999999999988, if
we render it to 18 digits.

>> And even if they did, floating point
>> could handle it just fine, if everyone agreed that around 15
>> digits of precision is good enough.
>
> For very small and very large sums of money, most banking systems
> will stay /very/ far away from floatingpoint in any form.

For very small? Can you elaborate on it. IEEE double can go to 1E-308,
right, and beyond that with subnormals.

> Better
> to do (expensive) fixed-precision math and get exact answers than
> to do (cheaper) floatingpoint math and get the final /financial/

Better to know what you're doing so you can make either one
sit up and beg, and avoid rolling over.

> answer wrong. That's how banks fail, and programmers get rich
> from rounding errors (watch the movie "Office Space").

Proof by comedy movie, okay.

Companies fail by taking away the red stapler from the reclusive nerd.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 8/10/2023 11:26 AM, Kaz Kylheku wrote:
> On 2023-08-10, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
[...]
> Proof by comedy movie, okay.
>
> Companies fail by taking away the red stapler from the reclusive nerd.

Indeed! Can be dangerous. Highly unstable person:

https://youtu.be/pQMuSotWCEs?t=44

Ouch! ;^o

Michael S <already5chosen@yahoo.com> writes:

> On Thursday, August 10, 2023 at 6:08:45 PM UTC+3, Ben Bacarisse wrote:
>> Michael S <already...@yahoo.com> writes:
>>
>> > On Thursday, August 10, 2023 at 2:01:55 AM UTC+3, Ben Bacarisse wrote:
>> >> Bart <b...@freeuk.com> writes:
>> >>
>> >> > On 09/08/2023 03:04, Ben Bacarisse wrote:
>> >> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> >> >>
>> >> >>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>> >> >>>>
>> >> >>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
>> >> >>>> variable to the name of the compiler:
>> >> >>>>
>> >> >>>> CC=bcc
>> >> >>>> ...
>> >> >>>> %.o: %.c
>> >> >>>> @$(QUIET) || echo " COMPILE $<"
>> >> >>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>> >> >>>>
>> >> >>> Exactly,
>> >> >>> Bart is right.
>> >> >>
>> >> >> You are deliberately ignoring the context. Bart wants gcc prog.c to
>> >> >> write to prog, but in the computer world I inhabit, you do that with
>> >> >> make prog.
>> >> >
>> >> > This is a good example of double standards.
>> >> >
>> >> > I've complained in the past about having to supply the .c extension to a
>> >> > /C/ compiler.
>> >> >
>> >> > Now here make does not need an extension.
>> >>
>> >> I call it consistency. A compiler is given the file to process, make is
>> >> given the file to build (AKA "make").
>> >
>> > I disagree.
>> OK, but your disagreement is about something else.
>> > Consistent design, a.k.a. principle of minimal surprise, would be for
>> > basal utility 'make' to have no built-in rules. On top of it, system
>> > can supply one or more extended utilities, probably implemented as
>> > shell scripts, that do have built-in rules.
>>
>> So you also disagree with Bart whose compiler has a built-in rule about
>> what file extension to assume. You probably won't bring that up, though.
>>
> Compiler and generic build utility are not in the same boat.
> It is less surprising to have defaults in compiler than to have built-in
> implicit rules in generic build utility.

I'm not sure I'd call it surprising as such but it's certainly
intellectually cleaner to have none and some invocation that loads a
standard set.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Michael S <already5chosen@yahoo.com> writes:
>
>> On Thursday, August 10, 2023 at 6:08:45 PM UTC+3, Ben Bacarisse wrote:
>>> Michael S <already...@yahoo.com> writes:
>>>
>>> > On Thursday, August 10, 2023 at 2:01:55 AM UTC+3, Ben Bacarisse wrote:
>>> >> Bart <b...@freeuk.com> writes:
>>> >>
>>> >> > On 09/08/2023 03:04, Ben Bacarisse wrote:
>>> >> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> >> >>
>>> >> >>> On Tuesday, 8 August 2023 at 18:32:21 UTC+1, Scott Lurndal wrote:
>>> >> >>>>
>>> >> >>>> 1) Using a make variable in the rule for '.c' -> '.o' and setting the
>>> >> >>>> variable to the name of the compiler:
>>> >> >>>>
>>> >> >>>> CC=bcc
>>> >> >>>> ...
>>> >> >>>> %.o: %.c
>>> >> >>>> @$(QUIET) || echo " COMPILE $<"
>>> >> >>>> $(HUSHCOMPILE)$(CC) $(CFLAGS) -MMD -MP -o $@ -c $<
>>> >> >>>>
>>> >> >>> Exactly,
>>> >> >>> Bart is right.
>>> >> >>
>>> >> >> You are deliberately ignoring the context. Bart wants gcc prog.c to
>>> >> >> write to prog, but in the computer world I inhabit, you do that with
>>> >> >> make prog.
>>> >> >
>>> >> > This is a good example of double standards.
>>> >> >
>>> >> > I've complained in the past about having to supply the .c extension to a
>>> >> > /C/ compiler.
>>> >> >
>>> >> > Now here make does not need an extension.
>>> >>
>>> >> I call it consistency. A compiler is given the file to process, make is
>>> >> given the file to build (AKA "make").
>>> >
>>> > I disagree.
>>> OK, but your disagreement is about something else.
>>> > Consistent design, a.k.a. principle of minimal surprise, would be for
>>> > basal utility 'make' to have no built-in rules. On top of it, system
>>> > can supply one or more extended utilities, probably implemented as
>>> > shell scripts, that do have built-in rules.
>>>
>>> So you also disagree with Bart whose compiler has a built-in rule about
>>> what file extension to assume. You probably won't bring that up, though.
>>>
>> Compiler and generic build utility are not in the same boat.
>> It is less surprising to have defaults in compiler than to have built-in
>> implicit rules in generic build utility.
>
>I'm not sure I'd call it surprising as such but it's certainly
>intellectually cleaner to have none and some invocation that loads a
>standard set.

Of course, if you don't want the built-in implicit rules, system V
make, POSIX make and gnu make support the -r command line option in addition to the
aforementioned .SUFFIXES.

czwartek, 10 sierpnia 2023 o 20:16:49 UTC+2 Kaz Kylheku napisał(a):
>
> DLLs are lacking in some technology like symbol versioning, linking
> in any direction (DLL cannot attach to symbols exported by executable)
> and such. Plus the use of clunky .lib files taht SO's don't require,
> and __decl(dllexport) and other cruft. (That pragma mechanism by
> which a source file indicates a needed DLL doesn't need a .lib file
> though, IIRC).
>

i dont remember as to this exe, though i remember i was testing it and
those relative usage - when i was writing more than one dll was making
some problems to me.. i dont remember hovever if you cant call functions in exe
though - problem was rather that when you want to compile dll using other dll you need to have the other build (becouse compilaton readed binary dll to check if symbols exist even if
linking is rruntime - this is in fact stupid but this is a consequence of fact that when
you link to a symbol compilers dont know in which of dlls you want to0 link it is,
and it need to put not only symbols but their parent module names in output) ..
it is mighty stupid bcouse you cant compile code that uses the dll that you dont really get
(unles there is some way providing this info on symbold what is the name of the
parent module of them, __declspec(dllimport) are not a problem though

it should be some other extension too like

__something "green fire.dll" //import module name for given symbols
{ __declspec(dllimport) int foo(int a);
__declspec(dllimport) float xx;
}

but i dont know if there is something like that

but besides in practice there are no problems with dlls at least when i use it
is a breat with butter

dlls are very likeable and i tell not a first time that if someone coded in c on windows he must
learn dlls becouse dlls are sorta part of practical c..and its real nice part (ofc it lacks types
encoded and call conventions which would allow to just get rid of headers - check my thread/post on it)

probably it would allow even normal c to get rid of headers as pif everything would just work without headers people just could not include them and tha wouldnt break codes

czwartek, 10 sierpnia 2023 o 23:44:31 UTC+2 fir napisał(a):
> czwartek, 10 sierpnia 2023 o 20:16:49 UTC+2 Kaz Kylheku napisał(a):
> >
> > DLLs are lacking in some technology like symbol versioning, linking
> > in any direction (DLL cannot attach to symbols exported by executable)
> > and such. Plus the use of clunky .lib files taht SO's don't require,
> > and __decl(dllexport) and other cruft. (That pragma mechanism by
> > which a source file indicates a needed DLL doesn't need a .lib file
> > though, IIRC).
> >
> i dont remember as to this exe, though i remember i was testing it and
> those relative usage - when i was writing more than one dll was making
> some problems to me.. i dont remember hovever if you cant call functions in exe
> though - problem was rather that when you want to compile dll using other dll you need to have the other build (becouse compilaton readed binary dll to check if symbols exist even if
> linking is rruntime - this is in fact stupid but this is a consequence of fact that when
> you link to a symbol compilers dont know in which of dlls you want to0 link it is,
> and it need to put not only symbols but their parent module names in output) ..
> it is mighty stupid bcouse you cant compile code that uses the dll that you dont really get
> (unles there is some way providing this info on symbold what is the name of the
> parent module of them, __declspec(dllimport) are not a problem though
>
> it should be some other extension too like
>
> __something "green fire.dll" //import module name for given symbols
> {
> __declspec(dllimport) int foo(int a);
> __declspec(dllimport) float xx;
> }
>

ofc "normal c" also has this error becouse when you put symbol names in
normal c header you would in fact also needed to enclose it in module name
and some { } better too

they didnt do this probably as some may say, the obj modules cant have duplicates becouse
in c code you couldnt call a symbol that has duplicates at all..but on assembly/binary level
you totally can as those symbold evenif 10 of them have identycal name are there
just 32 bit adresses each of other value so on binary level there is no problem
with duplicated names of imports

more better adding those enclosing module names just gives something like compile time
or link time checking - you dont mistake where somethig should be, also get better
compile/link errors and also simply could use thet extended headers info to link
without providing this info in commandline

> but i dont know if there is something like that
>
>
> but besides in practice there are no problems with dlls at least when i use it
> is a breat with butter
>
> dlls are very likeable and i tell not a first time that if someone coded in c on windows he must
> learn dlls becouse dlls are sorta part of practical c..and its real nice part (ofc it lacks types
> encoded and call conventions which would allow to just get rid of headers - check my thread/post on it)
>
> probably it would allow even normal c to get rid of headers as pif everything would just work without headers people just could not include them and tha wouldnt break codes

On 10/08/2023 19:16, Kaz Kylheku wrote:
> On 2023-08-10, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Ah, yes. DLL hell. Something that has not yet been an issue for
>> unix/linux, and hopefully never will.
>
> While DLLs have some issues, there are some aspects of DLL's that
> are better than shared libraries on Linux.
>
> The Unix people hit on a good idea in their C language implementation:
> that when a file contains an #include "..." directive, where the
> ... is a relative path name, it is resolved relative to the directory
> of that file which is invoking #include syntax is found.
>
> Windows does a similar thing for DLL's. A program can be shipped
> with its DLLs, which are easily found because they are in the
> same directory.
>
> This would be a huge improvement for shared libs. It's incredible
> that the developers of the ELF stuff didn't notice how
> nice #include is. Nobody every has to set a weird enviornment
> variable to get "foo.c" to find "foo.h".
>
> DLLs are lacking in some technology like symbol versioning, linking
> in any direction (DLL cannot attach to symbols exported by executable)
> and such. Plus the use of clunky .lib files taht SO's don't require,

That depends on compiler. gcc, tcc, bcc can directly link to DLLs. Ones
like MSVC use .lib files (I don't know why they are necessary).

> and __decl(dllexport) and other cruft.

This is C specific and seems to vary by compiler. I could never
understand how that works, and I've never used it.

With gcc generating the DLL, it seems to just export any function that
isn't static. bcc does the same, but tcc is peculiar.

So, how do you control what functions to export from a .so file?

On 10/08/2023 22:44, fir wrote:
> czwartek, 10 sierpnia 2023 o 20:16:49 UTC+2 Kaz Kylheku napisał(a):
>>
>> DLLs are lacking in some technology like symbol versioning, linking
>> in any direction (DLL cannot attach to symbols exported by executable)
>> and such. Plus the use of clunky .lib files taht SO's don't require,
>> and __decl(dllexport) and other cruft. (That pragma mechanism by
>> which a source file indicates a needed DLL doesn't need a .lib file
>> though, IIRC).
>>
>
> i dont remember as to this exe, though i remember i was testing it and
> those relative usage - when i was writing more than one dll was making
> some problems to me.. i dont remember hovever if you cant call functions in exe
> though - problem was rather that when you want to compile dll using other dll you need to have the other build (becouse compilaton readed binary dll to check if symbols exist even if
> linking is rruntime - this is in fact stupid but this is a consequence of fact that when
> you link to a symbol compilers dont know in which of dlls you want to0 link it is,
> and it need to put not only symbols but their parent module names in output) ..
> it is mighty stupid bcouse you cant compile code that uses the dll that you dont really get
> (unles there is some way providing this info on symbold what is the name of the
> parent module of them, __declspec(dllimport) are not a problem though
>
> it should be some other extension too like
>
> __something "green fire.dll" //import module name for given symbols
> {
> __declspec(dllimport) int foo(int a);
> __declspec(dllimport) float xx;
> }
>
> but i dont know if there is something like that
>
>
> but besides in practice there are no problems with dlls at least when i use it
> is a breat with butter
>
> dlls are very likeable and i tell not a first time that if someone coded in c on windows he must
> learn dlls becouse dlls are sorta part of practical c..and its real nice part (ofc it lacks types
> encoded and call conventions which would allow to just get rid of headers - check my thread/post on it)
>
> probably it would allow even normal c to get rid of headers as pif everything would just work without headers people just could not include them and tha wouldnt break codes

How would that work? To use a function exported from a DLL, you will
need a function signature, perhaps a set of usertypes, enums and #defines.

All the stuff that normally is provided by a header.

Where would that information come from?

(My own idea was for an interface info to be embedded inside the DLL,
and accessed by calling a special exported function. For C, that could
just return a string containing the normal header code.

But it would need cooperation from the people creating the DLL (who
could be writing in any language, not C).

And from C compilers to delve inside DLL files (and at an early stage
long before linking). Since C compilers can't even shake off
anachronisms like -lm and a.out, I can't see that happening.)

My idea was for my own private use

piątek, 11 sierpnia 2023 o 00:17:57 UTC+2 Bart napisał(a):
> On 10/08/2023 22:44, fir wrote:
> > czwartek, 10 sierpnia 2023 o 20:16:49 UTC+2 Kaz Kylheku napisał(a):
> >>
> >> DLLs are lacking in some technology like symbol versioning, linking
> >> in any direction (DLL cannot attach to symbols exported by executable)
> >> and such. Plus the use of clunky .lib files taht SO's don't require,
> >> and __decl(dllexport) and other cruft. (That pragma mechanism by
> >> which a source file indicates a needed DLL doesn't need a .lib file
> >> though, IIRC).
> >>
> >
> > i dont remember as to this exe, though i remember i was testing it and
> > those relative usage - when i was writing more than one dll was making
> > some problems to me.. i dont remember hovever if you cant call functions in exe
> > though - problem was rather that when you want to compile dll using other dll you need to have the other build (becouse compilaton readed binary dll to check if symbols exist even if
> > linking is rruntime - this is in fact stupid but this is a consequence of fact that when
> > you link to a symbol compilers dont know in which of dlls you want to0 link it is,
> > and it need to put not only symbols but their parent module names in output) ..
> > it is mighty stupid bcouse you cant compile code that uses the dll that you dont really get
> > (unles there is some way providing this info on symbold what is the name of the
> > parent module of them, __declspec(dllimport) are not a problem though
> >
> > it should be some other extension too like
> >
> > __something "green fire.dll" //import module name for given symbols
> > {
> > __declspec(dllimport) int foo(int a);
> > __declspec(dllimport) float xx;
> > }
> >
> > but i dont know if there is something like that
> >
> >
> > but besides in practice there are no problems with dlls at least when i use it
> > is a breat with butter
> >
> > dlls are very likeable and i tell not a first time that if someone coded in c on windows he must
> > learn dlls becouse dlls are sorta part of practical c..and its real nice part (ofc it lacks types
> > encoded and call conventions which would allow to just get rid of headers - check my thread/post on it)
> >
> > probably it would allow even normal c to get rid of headers as pif everything would just work without headers people just could not include them and tha wouldnt break codes
> How would that work? To use a function exported from a DLL, you will
> need a function signature, perhaps a set of usertypes, enums and #defines..
>
> All the stuff that normally is provided by a header.
>
> Where would that information come from?
>
> (My own idea was for an interface info to be embedded inside the DLL,
> and accessed by calling a special exported function. For C, that could
> just return a string containing the normal header code.
>
> But it would need cooperation from the people creating the DLL (who
> could be writing in any language, not C).
>
> And from C compilers to delve inside DLL files (and at an early stage
> long before linking). Since C compilers can't even shake off
> anachronisms like -lm and a.out, I can't see that happening.)
>
>
>
> My idea was for my own private use
doi
lern how PE format works coz it is really important - not mucnh pleasant to read but important as hell

as how to encode this see a thread named
"new abi proposition (for modules/dynamic libraries)" from a month ago (13 VII)
doing this is not a problem PE (exe/dll) format is open to a section, in fact .iidata import section is just mainly a list of strings with dll names and its symbol names to import - it also has this array of pointers but empty (afair, or other junk) - those names are important as windows links by names - and just fill the pointers with proper values

i mean when i gor my program.exe that uses my green.fire.dll then it works like that::

windows load green.fire.dll into ram, the code for function "SetupWindow5" is placed in some ram area (in program.exe space) dll has export table where "SetupWindow5" exist and offset in dll where asm code for it is stored in that dll ...program.exe also is loaded in ram its import section is then loaded in ram it also has "SetupWindow5" string and correspondant junk pointer which is then fulfilled with real adres, so when i write

call ("green.fire.dll"->SetupWindow5)

then it really is something like call (0x00401034) which pointer is in import section of loaded exe
(whuch was loaded under say 0x00400000) and its value points to sax 0x0050cccc where code oof SetpuWindow5 of dll was loaded

that was digression but imo its important to understend it well

import section is just section in PE/dll file - but it contais literally only module names and symbol names with nothing more (except that junk pointers) - you need just add another section
in dfil file containing calling convention for each function symbol, and possibly also list of argument types and names, and even type definitions

roughly how it should look like i described in that post month ago

i could do it myself as i got my own assembler - and maybe i should becouse if someone else would do that before there is a chance it will do it more bad than i (im not in hurry hovever and it can take me 10 years becouse i got some other obligations and not code to much recent years)

piątek, 11 sierpnia 2023 o 01:06:37 UTC+2 fir napisał(a):
> piątek, 11 sierpnia 2023 o 00:17:57 UTC+2 Bart napisał(a):
> > On 10/08/2023 22:44, fir wrote:
> > > czwartek, 10 sierpnia 2023 o 20:16:49 UTC+2 Kaz Kylheku napisał(a):
> > >>
> > >> DLLs are lacking in some technology like symbol versioning, linking
> > >> in any direction (DLL cannot attach to symbols exported by executable)
> > >> and such. Plus the use of clunky .lib files taht SO's don't require,
> > >> and __decl(dllexport) and other cruft. (That pragma mechanism by
> > >> which a source file indicates a needed DLL doesn't need a .lib file
> > >> though, IIRC).
> > >>
> > >
> > > i dont remember as to this exe, though i remember i was testing it and
> > > those relative usage - when i was writing more than one dll was making
> > > some problems to me.. i dont remember hovever if you cant call functions in exe
> > > though - problem was rather that when you want to compile dll using other dll you need to have the other build (becouse compilaton readed binary dll to check if symbols exist even if
> > > linking is rruntime - this is in fact stupid but this is a consequence of fact that when
> > > you link to a symbol compilers dont know in which of dlls you want to0 link it is,
> > > and it need to put not only symbols but their parent module names in output) ..
> > > it is mighty stupid bcouse you cant compile code that uses the dll that you dont really get
> > > (unles there is some way providing this info on symbold what is the name of the
> > > parent module of them, __declspec(dllimport) are not a problem though
> > >
> > > it should be some other extension too like
> > >
> > > __something "green fire.dll" //import module name for given symbols
> > > {
> > > __declspec(dllimport) int foo(int a);
> > > __declspec(dllimport) float xx;
> > > }
> > >
> > > but i dont know if there is something like that
> > >
> > >
> > > but besides in practice there are no problems with dlls at least when i use it
> > > is a breat with butter
> > >
> > > dlls are very likeable and i tell not a first time that if someone coded in c on windows he must
> > > learn dlls becouse dlls are sorta part of practical c..and its real nice part (ofc it lacks types
> > > encoded and call conventions which would allow to just get rid of headers - check my thread/post on it)
> > >
> > > probably it would allow even normal c to get rid of headers as pif everything would just work without headers people just could not include them and tha wouldnt break codes
> > How would that work? To use a function exported from a DLL, you will
> > need a function signature, perhaps a set of usertypes, enums and #defines.
> >
> > All the stuff that normally is provided by a header.
> >
> > Where would that information come from?
> >
> > (My own idea was for an interface info to be embedded inside the DLL,
> > and accessed by calling a special exported function. For C, that could
> > just return a string containing the normal header code.
> >
> > But it would need cooperation from the people creating the DLL (who
> > could be writing in any language, not C).
> >
> > And from C compilers to delve inside DLL files (and at an early stage
> > long before linking). Since C compilers can't even shake off
> > anachronisms like -lm and a.out, I can't see that happening.)
> >
> >
> >
> > My idea was for my own private use
> doi
> lern how PE format works coz it is really important - not mucnh pleasant to read but important as hell
>
> as how to encode this see a thread named
> "new abi proposition (for modules/dynamic libraries)" from a month ago (13 VII)
>
> doing this is not a problem PE (exe/dll) format is open to a section, in fact .iidata import section is just mainly a list of strings with dll names and its symbol names to import - it also has this array of pointers but empty (afair, or other junk) - those names are important as windows links by names - and just fill the pointers with proper values
>
> i mean when i gor my program.exe that uses my green.fire.dll then it works like that::
>
> windows load green.fire.dll into ram, the code for function "SetupWindow5" is placed in some ram area (in program.exe space) dll has export table where "SetupWindow5" exist and offset in dll where asm code for it is stored in that dll ...program.exe also is loaded in ram its import section is then loaded in ram it also has "SetupWindow5" string and correspondant junk pointer which is then fulfilled with real adres, so when i write
>
> call ("green.fire.dll"->SetupWindow5)
>
> then it really is something like call (0x00401034) which pointer is in import section of loaded exe
> (whuch was loaded under say 0x00400000) and its value points to sax 0x0050cccc where code oof SetpuWindow5 of dll was loaded
>
> that was digression but imo its important to understend it well
>
> import section is just section in PE/dll file - but it contais literally only module names and symbol names with nothing more (except that junk pointers) - you need just add another section
> in dfil file containing calling convention for each function symbol, and possibly also list of argument types and names, and even type definitions
>
> roughly how it should look like i described in that post month ago
>
> i could do it myself as i got my own assembler - and maybe i should becouse if someone else would do that before there is a chance it will do it more bad than i (im not in hurry hovever and it can take me 10 years becouse i got some other obligations and not code to much recent years)

and how it would work, simply when compiling with -l"dllname" coimpiler would terat such dll section contents as tidays header... this has this disadvantage you need binary dll to compile into it buts its analog to just have a header, one also could wrote extern declarations by hand and compile without it

piątek, 11 sierpnia 2023 o 01:06:37 UTC+2 fir napisał(a):
>
> call ("green.fire.dll"->SetupWindow5)
>
> then it really is something like call (0x00401034) which pointer is in import section of loaded exe
> (whuch was loaded under say 0x00400000) and its value points to sax 0x0050cccc where code oof SetpuWindow5 of dll was loaded
>

more precisely values are for example

Building imports :

912 (0x0390) bytes stored in import section

green.fire.dll
frame_size_x (0x00402354)
frame_size_y (0x00402358)
ClearFrameData (0x0040235c)
frame_bitmap (0x00402360)
RegisterMouseMove (0x00402364)
RegisterLeftMouseButtonDown (0x00402368)
RegisterRightMouseButtonDown (0x0040236c)
RegisterKeyDown (0x00402370)
RegisterOnResize (0x00402374)
RegisterRunFrame (0x00402378)
SetSleepValue (0x0040237c)
SetupWindow3 (0x00402380)

msvcrt.dll
printf (0x00402388)

as as far as i knoe exe is loaded typically under 0x00400000
in my case code first than imports then data (static arrays) ..dll afait must be loaded
somewhere 0x004xxxxx - 0x7ffxxxxx, also heap is probably there

in fact it would be worth to print out thet pointers

exe code may use fixed adresses of jumps and data acces as its just loaded under known adress, dlls must provide fixups as dll must be loaded under varoius adress and need to apply fixups then
(old ollydbg debbugger for windows shows nice info with that data)

piątek, 11 sierpnia 2023 o 01:39:12 UTC+2 fir napisał(a):

> (old ollydbg debbugger for windows shows nice info with that data)

olly for example shows that nice memory map (when attached to my game protorype
codenamed tusk (turnbased space shooter)

its nice coz it shows what dlls are loaded and where, it also shows
which section occupies how many bytes - the biggest are .bbs it is
zero inicialized static arrays..it shows for example i do not much
optymalised my programs in this aspect (which is kinda bug as in many files
i just declated sbig tatic arrays just to be handy, but its probbaly better to use
realloc seeds and not to go with that static arrays to much
(technically its still no harm as thetre unused and not even physical memory is mapped but
logical areas are wasted)

Memory map
Address Size (Decimal) Owner Section Contains Type Access Initial Mapped as
00010000 00001000 (4096.) 00010000 (itself) Priv 00021004 RW RW
00020000 00001000 (4096.) 00020000 (itself) Priv 00021004 RW RW
0022C000 00001000 (4096.) 00030000 Priv 00021104 RW Guar RW
0022D000 00003000 (12288.) 00030000 stack of main thread Priv 00021104 RW Guar RW
00230000 00003000 (12288.) 00230000 (itself) Map 00041002 R R
00240000 00020000 (131072.) 00240000 (itself) Priv 00021004 RW RW
00340000 00006000 (24576.) 00340000 (itself) Priv 00021004 RW RW
00350000 00003000 (12288.) 00350000 (itself) Map 00041004 RW RW
00360000 00016000 (90112.) 00360000 (itself) Map 00041002 R R \Device\HarddiskVolume1\WINDOWS\system32\unicode.nls
00380000 00041000 (266240.) 00380000 (itself) Map 00041002 R R \Device\HarddiskVolume1\WINDOWS\system32\locale.nls
003D0000 00006000 (24576.) 003D0000 (itself) Map 00041002 R R \Device\HarddiskVolume1\WINDOWS\system32\sorttbls.nls
003E0000 00001000 (4096.) WS2_32 003E0000 (itself) PE header Imag 01001002 R RWE
003E1000 00013000 (77824.) WS2_32 003E0000 .text code,imports,exports Imag 01001002 R RWE
003F4000 00001000 (4096.) WS2_32 003E0000 .data data Imag 01001002 R RWE
003F5000 00001000 (4096.) WS2_32 003E0000 .rsrc resources Imag 01001002 R RWE
003F6000 00001000 (4096.) WS2_32 003E0000 .reloc relocations Imag 01001002 R RWE
00400000 00001000 (4096.) tusk 00400000 (itself) PE header Imag 01001002 R RWE
00401000 00030000 (196608.) tusk 00400000 .text code Imag 01001002 R RWE
00431000 00001000 (4096.) tusk 00400000 .data data Imag 01001002 R RWE
00432000 00004000 (16384.) tusk 00400000 .rdata Imag 01001002 R RWE
00436000 00001000 (4096.) tusk 00400000 .eh_fram Imag 01001002 R RWE
00437000 01966000 (26632192.) tusk 00400000 .bss Imag 01001002 R RWE
01D9D000 00001000 (4096.) tusk 00400000 .idata imports Imag 01001002 R RWE
01D9E000 00001000 (4096.) tusk 00400000 .CRT Imag 01001002 R RWE
01D9F000 00001000 (4096.) tusk 00400000 .tls Imag 01001002 R RWE
01DA0000 00004000 (16384.) tusk 00400000 .rsrc resources Imag 01001002 R RWE
01DB0000 00041000 (266240.) 01DB0000 (itself) Map 00041002 R R \Device\HarddiskVolume1\WINDOWS\system32\sortkey.nls
01E00000 00041000 (266240.) 01E00000 (itself) Map 00041002 R R
01E50000 00001000 (4096.) WS2HELP 01E50000 (itself) PE header Imag 01001002 R RWE
01E51000 00004000 (16384.) WS2HELP 01E50000 .text code,imports,exports Imag 01001002 R RWE
01E55000 00001000 (4096.) WS2HELP 01E50000 .data data Imag 01001002 R RWE
01E56000 00001000 (4096.) WS2HELP 01E50000 .rsrc resources Imag 01001002 R RWE
01E57000 00001000 (4096.) WS2HELP 01E50000 .reloc relocations Imag 01001002 R RWE
01E60000 00004000 (16384.) 01E60000 (itself) Map 00041020 R E R E
01F20000 00002000 (8192.) 01E60000 Map 00041020 R E R E
01F30000 00103000 (1060864.) 01F30000 (itself) Map 00041002 R R
02040000 00001000 (4096.) 02040000 (itself) Priv 00021004 RW RW
02050000 00073000 (471040.) 02050000 (itself) Map 00041020 R E R E
02350000 00001000 (4096.) 02350000 (itself) Priv 00021004 RW RW
02360000 00004000 (16384.) 02360000 (itself) Priv 00021004 RW RW
02370000 00003000 (12288.) 02370000 (itself) Map 00041002 R R \Device\HarddiskVolume1\WINDOWS\system32\ctype.nls
02380000 00001000 (4096.) 02380000 (itself) Priv 00021004 RW RW
02400000 00004000 (16384.) 02400000 (itself) Priv 00021004 RW RW
02410000 00002000 (8192.) 02410000 (itself) Map 00041002 R R
02420000 00001000 (4096.) 02420000 (itself) Map 00041004 RW RW
02430000 00002000 (8192.) 02430000 (itself) Map 00041002 R R
02440000 00003000 (12288.) 02440000 (itself) Priv 00021004 RW RW
02480000 00011000 (69632.) 02480000 (itself) Map 00041002 R R \Device\HarddiskVolume1\WINDOWS\system32\c_1252.nls
024AE000 00001000 (4096.) 024A0000 Priv 00021104 RW Guar RW
024AF000 00001000 (4096.) 024A0000 stack of thread 0000 Priv 00021104 RW Guar RW
024B0000 00002000 (8192.) 024B0000 (itself) Map 00041002 R R
024C0000 0022C000 (2277376.) 024C0000 (itself) Priv 00021004 RW RW
026F0000 00040000 (262144.) 026F0000 (itself) Map 00041002 R R
02730000 00100000 (1048576.) 02730000 (itself) Priv 00021004 RW RW
02A2E000 00001000 (4096.) 02830000 Priv 00021104 RW Guar RW
02A2F000 00001000 (4096.) 02830000 stack of thread 0000 Priv 00021104 RW Guar RW
02C2D000 00001000 (4096.) 02A30000 Priv 00021104 RW Guar RW
02C2E000 00002000 (8192.) 02A30000 stack of thread 0000 Priv 00021104 RW Guar RW
5D520000 00001000 (4096.) COMCTL32 5D520000 (itself) PE header Imag 01001002 R RWE
5D521000 00071000 (462848.) COMCTL32 5D520000 .text code,imports,exports Imag 01001002 R RWE
5D592000 00003000 (12288.) COMCTL32 5D520000 .data data Imag 01001002 R RWE
5D595000 00020000 (131072.) COMCTL32 5D520000 .rsrc resources Imag 01001002 R RWE
5D5B5000 00005000 (20480.) COMCTL32 5D520000 .reloc relocations Imag 01001002 R RWE
64840000 00001000 (4096.) green_fi 64840000 (itself) PE header Imag 01001002 R RWE
64841000 00044000 (278528.) green_fi 64840000 .text code Imag 01001002 R RWE
64885000 00026000 (155648.) green_fi 64840000 .data data Imag 01001002 R RWE
648AB000 00002000 (8192.) green_fi 64840000 .rdata Imag 01001002 R RWE
648AD000 00001000 (4096.) green_fi 64840000 .eh_fram Imag 01001002 R RWE
648AE000 0DDC4000 (232538112.) green_fi 64840000 .bss Imag 01001002 R RWE
72672000 00004000 (16384.) green_fi 64840000 .edata exports Imag 01001002 R RWE
72676000 00002000 (8192.) green_fi 64840000 .idata imports Imag 01001002 R RWE
72678000 00001000 (4096.) green_fi 64840000 .CRT Imag 01001002 R RWE
72679000 00001000 (4096.) green_fi 64840000 .tls Imag 01001002 R RWE
7267A000 00001000 (4096.) green_fi 64840000 .rsrc resources Imag 01001002 R RWE
7267B000 00004000 (16384.) green_fi 64840000 .reloc relocations Imag 01001002 R RWE
72CA0000 00001000 (4096.) msacm32 72CA0000 (itself) PE header Imag 01001002 R RWE
72CA1000 00003000 (12288.) msacm32 72CA0000 .text code,imports,exports Imag 01001002 R RWE
72CA4000 00001000 (4096.) msacm32 72CA0000 .data data Imag 01001002 R RWE
72CA5000 00002000 (8192.) msacm32 72CA0000 .rsrc resources Imag 01001002 R RWE
72CA7000 00001000 (4096.) msacm32 72CA0000 .reloc relocations Imag 01001002 R RWE
72CB0000 00001000 (4096.) wdmaud 72CB0000 (itself) PE header Imag 01001002 R RWE
72CB1000 00005000 (20480.) wdmaud 72CB0000 .text code,imports,exports Imag 01001002 R RWE
72CB6000 00001000 (4096.) wdmaud 72CB0000 .data data Imag 01001002 R RWE
72CB7000 00001000 (4096.) wdmaud 72CB0000 .rsrc resources Imag 01001002 R RWE
72CB8000 00001000 (4096.) wdmaud 72CB0000 .reloc relocations Imag 01001002 R RWE
76380000 00001000 (4096.) COMDLG32 76380000 (itself) PE header Imag 01001002 R RWE
76381000 00030000 (196608.) COMDLG32 76380000 .text code,imports,exports Imag 01001002 R RWE
763B1000 00004000 (16384.) COMDLG32 76380000 .data data Imag 01001002 R RWE
763B5000 00011000 (69632.) COMDLG32 76380000 .rsrc resources Imag 01001002 R RWE
763C6000 00003000 (12288.) COMDLG32 76380000 .reloc relocations Imag 01001002 R RWE
76B20000 00001000 (4096.) WINMM 76B20000 (itself) PE header Imag 01001002 R RWE
76B21000 0001F000 (126976.) WINMM 76B20000 .text code,imports,exports Imag 01001002 R RWE
76B40000 00002000 (8192.) WINMM 76B20000 .data data Imag 01001002 R RWE
76B42000 0000A000 (40960.) WINMM 76B20000 .rsrc resources Imag 01001002 R RWE
76B4C000 00002000 (8192.) WINMM 76B20000 .reloc relocations Imag 01001002 R RWE
76BE0000 00001000 (4096.) PSAPI 76BE0000 (itself) PE header Imag 01001002 R RWE
76BE1000 00004000 (16384.) PSAPI 76BE0000 .text code,imports,exports Imag 01001002 R RWE
76BE5000 00004000 (16384.) PSAPI 76BE0000 .data data Imag 01001002 R RWE
76BE9000 00001000 (4096.) PSAPI 76BE0000 .rsrc resources Imag 01001002 R RWE
76BEA000 00001000 (4096.) PSAPI 76BE0000 .reloc relocations Imag 01001002 R RWE
76C20000 00001000 (4096.) WINTRUST 76C20000 (itself) PE header Imag 01001002 R RWE
76C21000 00029000 (167936.) WINTRUST 76C20000 .text code,imports,exports Imag 01001002 R RWE
76C4A000 00001000 (4096.) WINTRUST 76C20000 .data data Imag 01001002 R RWE
76C4B000 00001000 (4096.) WINTRUST 76C20000 .rsrc resources Imag 01001002 R RWE
76C4C000 00002000 (8192.) WINTRUST 76C20000 .reloc relocations Imag 01001002 R RWE
76C80000 00001000 (4096.) IMAGEHLP 76C80000 (itself) PE header Imag 01001002 R RWE
76C81000 00022000 (139264.) IMAGEHLP 76C80000 .text code,imports,exports Imag 01001002 R RWE
76CA3000 00002000 (8192.) IMAGEHLP 76C80000 .data data Imag 01001002 R RWE
76CA5000 00001000 (4096.) IMAGEHLP 76C80000 .rsrc resources Imag 01001002 R RWE
76CA6000 00002000 (8192.) IMAGEHLP 76C80000 .reloc relocations Imag 01001002 R RWE
773C0000 00001000 (4096.) comctl_1 773C0000 (itself) PE header Imag 01001002 R RWE
773C1000 00091000 (593920.) comctl_1 773C0000 .text code,imports,exports Imag 01001002 R RWE
77452000 00001000 (4096.) comctl_1 773C0000 .data data Imag 01001002 R RWE
77453000 0006A000 (434176.) comctl_1 773C0000 .rsrc resources Imag 01001002 R RWE
774BD000 00006000 (24576.) comctl_1 773C0000 .reloc relocations Imag 01001002 R RWE
77A70000 00001000 (4096.) CRYPT32 77A70000 (itself) PE header Imag 01001002 R RWE
77A71000 00085000 (544768.) CRYPT32 77A70000 .text code,imports,exports Imag 01001002 R RWE
77AF6000 00003000 (12288.) CRYPT32 77A70000 .data data Imag 01001002 R RWE
77AF9000 00008000 (32768.) CRYPT32 77A70000 .rsrc resources Imag 01001002 R RWE
77B01000 00005000 (20480.) CRYPT32 77A70000 .reloc relocations Imag 01001002 R RWE
77B10000 00001000 (4096.) MSASN1 77B10000 (itself) PE header Imag 01001002 R RWE
77B11000 0000E000 (57344.) MSASN1 77B10000 .text code,imports,exports Imag 01001002 R RWE
77B1F000 00001000 (4096.) MSASN1 77B10000 .data data Imag 01001002 R RWE
77B20000 00001000 (4096.) MSASN1 77B10000 .rsrc resources Imag 01001002 R RWE
77B21000 00001000 (4096.) MSASN1 77B10000 .reloc relocations Imag 01001002 R RWE
77BC0000 00001000 (4096.) midimap 77BC0000 (itself) PE header Imag 01001002 R RWE
77BC1000 00003000 (12288.) midimap 77BC0000 .text code,imports,exports Imag 01001002 R RWE
77BC4000 00001000 (4096.) midimap 77BC0000 .data data Imag 01001002 R RWE
77BC5000 00001000 (4096.) midimap 77BC0000 .rsrc resources Imag 01001002 R RWE
77BC6000 00001000 (4096.) midimap 77BC0000 .reloc relocations Imag 01001002 R RWE
77BD0000 00001000 (4096.) MSACM3_1 77BD0000 (itself) PE header Imag 01001002 R RWE
77BD1000 00010000 (65536.) MSACM3_1 77BD0000 .text code,imports,exports Imag 01001002 R RWE
77BE1000 00001000 (4096.) MSACM3_1 77BD0000 .data data Imag 01001002 R RWE
77BE2000 00002000 (8192.) MSACM3_1 77BD0000 .rsrc resources Imag 01001002 R RWE
77BE4000 00001000 (4096.) MSACM3_1 77BD0000 .reloc relocations Imag 01001002 R RWE
77C00000 00001000 (4096.) msvcrt 77C00000 (itself) PE header Imag 01001002 R RWE
77C01000 0004C000 (311296.) msvcrt 77C00000 .text code,imports,exports Imag 01001002 R RWE
77C4D000 00007000 (28672.) msvcrt 77C00000 .data data Imag 01001002 R RWE
77C54000 00001000 (4096.) msvcrt 77C00000 .rsrc resources Imag 01001002 R RWE
77C55000 00003000 (12288.) msvcrt 77C00000 .reloc relocations Imag 01001002 R RWE
77DC0000 00001000 (4096.) ADVAPI32 77DC0000 (itself) PE header Imag 01001002 R RWE
77DC1000 00075000 (479232.) ADVAPI32 77DC0000 .text code,imports,exports Imag 01001002 R RWE
77E36000 00005000 (20480.) ADVAPI32 77DC0000 .data data Imag 01001002 R RWE
77E3B000 0002C000 (180224.) ADVAPI32 77DC0000 .rsrc resources Imag 01001002 R RWE
77E67000 00005000 (20480.) ADVAPI32 77DC0000 .reloc relocations Imag 01001002 R RWE
77E70000 00001000 (4096.) RPCRT4 77E70000 (itself) PE header Imag 01001002 R RWE
77E71000 00083000 (536576.) RPCRT4 77E70000 .text code,imports,exports Imag 01001002 R RWE
77EF4000 00007000 (28672.) RPCRT4 77E70000 .orpc code Imag 01001002 R RWE
77EFB000 00001000 (4096.) RPCRT4 77E70000 .data data Imag 01001002 R RWE
77EFC000 00001000 (4096.) RPCRT4 77E70000 .rsrc resources Imag 01001002 R RWE
77EFD000 00005000 (20480.) RPCRT4 77E70000 .reloc relocations Imag 01001002 R RWE
77F10000 00001000 (4096.) GDI32 77F10000 (itself) PE header Imag 01001002 R RWE
77F11000 00043000 (274432.) GDI32 77F10000 .text code,imports,exports Imag 01001002 R RWE
77F54000 00002000 (8192.) GDI32 77F10000 .data data Imag 01001002 R RWE
77F56000 00001000 (4096.) GDI32 77F10000 .rsrc resources Imag 01001002 R RWE
77F57000 00002000 (8192.) GDI32 77F10000 .reloc relocations Imag 01001002 R RWE
77F60000 00001000 (4096.) SHLWAPI 77F60000 (itself) PE header Imag 01001002 R RWE
77F61000 0006C000 (442368.) SHLWAPI 77F60000 .text code,imports,exports Imag 01001002 R RWE
77FCD000 00001000 (4096.) SHLWAPI 77F60000 .data data Imag 01001002 R RWE
77FCE000 00002000 (8192.) SHLWAPI 77F60000 .rsrc resources Imag 01001002 R RWE
77FD0000 00006000 (24576.) SHLWAPI 77F60000 .reloc relocations Imag 01001002 R RWE
77FE0000 00001000 (4096.) Secur32 77FE0000 (itself) PE header Imag 01001002 R RWE
77FE1000 0000D000 (53248.) Secur32 77FE0000 .text code,imports,exports Imag 01001002 R RWE
77FEE000 00001000 (4096.) Secur32 77FE0000 .data data Imag 01001002 R RWE
77FEF000 00001000 (4096.) Secur32 77FE0000 .rsrc resources Imag 01001002 R RWE
77FF0000 00001000 (4096.) Secur32 77FE0000 .reloc relocations Imag 01001002 R RWE
7C800000 00001000 (4096.) kernel32 7C800000 (itself) PE header Imag 01001002 R RWE
7C801000 00084000 (540672.) kernel32 7C800000 .text code,imports,exports Imag 01001002 R RWE
7C885000 00005000 (20480.) kernel32 7C800000 .data data Imag 01001002 R RWE
7C88A000 0006D000 (446464.) kernel32 7C800000 .rsrc resources Imag 01001002 R RWE
7C8F7000 00006000 (24576.) kernel32 7C800000 .reloc relocations Imag 01001002 R RWE
7C900000 00001000 (4096.) ntdll 7C900000 (itself) PE header Imag 01001002 R RWE
7C901000 0007A000 (499712.) ntdll 7C900000 .text code,exports Imag 01001002 R RWE
7C97B000 00005000 (20480.) ntdll 7C900000 .data data Imag 01001002 R RWE
7C980000 0002E000 (188416.) ntdll 7C900000 .rsrc resources Imag 01001002 R RWE
7C9AE000 00003000 (12288.) ntdll 7C900000 .reloc relocations Imag 01001002 R RWE
7C9C0000 00001000 (4096.) SHELL32 7C9C0000 (itself) PE header Imag 01001002 R RWE
7C9C1000 001FE000 (2088960.) SHELL32 7C9C0000 .text code,imports,exports Imag 01001002 R RWE
7CBBF000 0001D000 (118784.) SHELL32 7C9C0000 .data data Imag 01001002 R RWE
7CBDC000 005E7000 (6189056.) SHELL32 7C9C0000 .rsrc resources Imag 01001002 R RWE
7D1C3000 0001B000 (110592.) SHELL32 7C9C0000 .reloc relocations Imag 01001002 R RWE
7E360000 00001000 (4096.) USER32 7E360000 (itself) PE header Imag 01001002 R RWE
7E361000 00060000 (393216.) USER32 7E360000 .text code,imports,exports Imag 01001002 R RWE
7E3C1000 00002000 (8192.) USER32 7E360000 .data data Imag 01001002 R RWE
7E3C3000 0002B000 (176128.) USER32 7E360000 .rsrc resources Imag 01001002 R RWE
7E3EE000 00003000 (12288.) USER32 7E360000 .reloc relocations Imag 01001002 R RWE
7F6F0000 00007000 (28672.) 7F6F0000 (itself) Map 00041020 R E R E
7FFB0000 00024000 (147456.) 7FFB0000 (itself) Map 00041002 R R
7FFD9000 00001000 (4096.) 7FFD9000 (itself) Priv 00021004 RW RW
7FFDC000 00001000 (4096.) 7FFDC000 (itself) data block of thread Priv 00021004 RW RW
7FFDD000 00001000 (4096.) 7FFDD000 (itself) data block of thread Priv 00021004 RW RW
7FFDE000 00001000 (4096.) 7FFDE000 (itself) data block of thread Priv 00021004 RW RW
7FFDF000 00001000 (4096.) 7FFDF000 (itself) data block of main t Priv 00021004 RW RW
7FFE0000 00001000 (4096.) 7FFE0000 (itself) Priv 00021002 R R

On 11/08/2023 00:06, fir wrote:
> piątek, 11 sierpnia 2023 o 00:17:57 UTC+2 Bart napisał(a):
>> On 10/08/2023 22:44, fir wrote:
>>> czwartek, 10 sierpnia 2023 o 20:16:49 UTC+2 Kaz Kylheku napisał(a):
>>>>
>>>> DLLs are lacking in some technology like symbol versioning, linking
>>>> in any direction (DLL cannot attach to symbols exported by executable)
>>>> and such. Plus the use of clunky .lib files taht SO's don't require,
>>>> and __decl(dllexport) and other cruft. (That pragma mechanism by
>>>> which a source file indicates a needed DLL doesn't need a .lib file
>>>> though, IIRC).
>>>>
>>>
>>> i dont remember as to this exe, though i remember i was testing it and
>>> those relative usage - when i was writing more than one dll was making
>>> some problems to me.. i dont remember hovever if you cant call
functions in exe
>>> though - problem was rather that when you want to compile dll using
other dll you need to have the other build (becouse compilaton readed
binary dll to check if symbols exist even if
>>> linking is rruntime - this is in fact stupid but this is a
consequence of fact that when
>>> you link to a symbol compilers dont know in which of dlls you want
to0 link it is,
>>> and it need to put not only symbols but their parent module names
in output) ..
>>> it is mighty stupid bcouse you cant compile code that uses the dll
that you dont really get
>>> (unles there is some way providing this info on symbold what is the
name of the
>>> parent module of them, __declspec(dllimport) are not a problem though
>>>
>>> it should be some other extension too like
>>>
>>> __something "green fire.dll" //import module name for given symbols
>>> {
>>> __declspec(dllimport) int foo(int a);
>>> __declspec(dllimport) float xx;
>>> }
>>>
>>> but i dont know if there is something like that
>>>
>>>
>>> but besides in practice there are no problems with dlls at least
when i use it
>>> is a breat with butter
>>>
>>> dlls are very likeable and i tell not a first time that if someone
coded in c on windows he must
>>> learn dlls becouse dlls are sorta part of practical c..and its real
nice part (ofc it lacks types
>>> encoded and call conventions which would allow to just get rid of
headers - check my thread/post on it)
>>>
>>> probably it would allow even normal c to get rid of headers as pif
everything would just work without headers people just could not include
them and tha wouldnt break codes
>> How would that work? To use a function exported from a DLL, you will
>> need a function signature, perhaps a set of usertypes, enums and
#defines.
>>
>> All the stuff that normally is provided by a header.
>>
>> Where would that information come from?
>>
>> (My own idea was for an interface info to be embedded inside the DLL,
>> and accessed by calling a special exported function. For C, that could
>> just return a string containing the normal header code.
>>
>> But it would need cooperation from the people creating the DLL (who
>> could be writing in any language, not C).
>>
>> And from C compilers to delve inside DLL files (and at an early stage
>> long before linking). Since C compilers can't even shake off
>> anachronisms like -lm and a.out, I can't see that happening.)
>>
>>
>>
>> My idea was for my own private use
> doi
> lern how PE format works coz it is really important - not mucnh
pleasant to read but important as hell

You really don't need to disect a DLL file to extract some data from it.
A regular interface will do.

For example, for a DLL that exports one function 'add()', add this extra
function:

char* header = "int add(int, int);\n";
char* getheader(void) { return header;}

and create a DLL like 'lib.dll'.

Now, in the compiler that wants to import functions from lib.dll, use
code like this:

#include <stdio.h>
#include <windows.h>

int main(void) {
void* handle;
char* (*fnptr)(void);

handle=LoadLibrary("lib.dll");
if (handle) {
fnptr=GetProcAddress(handle, "getheader");
if (fnptr)
printf("Header = %s\n", fnptr());
}
}

Calling getheader() returns the same string as including a header file
like 'lib.h'.

No need to be delving inside the PE format.

Actually, as written, that 'header' variable is exported also, so you
can directly access that, but I prefer to do it via a function.

And, PE is a terrible, terrible format. Only get into as last resort.

piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
> On 11/08/2023 00:06, fir wrote:
> > piątek, 11 sierpnia 2023 o 00:17:57 UTC+2 Bart napisał(a):
> >> On 10/08/2023 22:44, fir wrote:
> >>> czwartek, 10 sierpnia 2023 o 20:16:49 UTC+2 Kaz Kylheku napisał(a):
> >>>>
> >>>> DLLs are lacking in some technology like symbol versioning, linking
> >>>> in any direction (DLL cannot attach to symbols exported by executable)
> >>>> and such. Plus the use of clunky .lib files taht SO's don't require,
> >>>> and __decl(dllexport) and other cruft. (That pragma mechanism by
> >>>> which a source file indicates a needed DLL doesn't need a .lib file
> >>>> though, IIRC).
> >>>>
> >>>
> >>> i dont remember as to this exe, though i remember i was testing it and
> >>> those relative usage - when i was writing more than one dll was making
> >>> some problems to me.. i dont remember hovever if you cant call
> functions in exe
> >>> though - problem was rather that when you want to compile dll using
> other dll you need to have the other build (becouse compilaton readed
> binary dll to check if symbols exist even if
> >>> linking is rruntime - this is in fact stupid but this is a
> consequence of fact that when
> >>> you link to a symbol compilers dont know in which of dlls you want
> to0 link it is,
> >>> and it need to put not only symbols but their parent module names
> in output) ..
> >>> it is mighty stupid bcouse you cant compile code that uses the dll
> that you dont really get
> >>> (unles there is some way providing this info on symbold what is the
> name of the
> >>> parent module of them, __declspec(dllimport) are not a problem though
> >>>
> >>> it should be some other extension too like
> >>>
> >>> __something "green fire.dll" //import module name for given symbols
> >>> {
> >>> __declspec(dllimport) int foo(int a);
> >>> __declspec(dllimport) float xx;
> >>> }
> >>>
> >>> but i dont know if there is something like that
> >>>
> >>>
> >>> but besides in practice there are no problems with dlls at least
> when i use it
> >>> is a breat with butter
> >>>
> >>> dlls are very likeable and i tell not a first time that if someone
> coded in c on windows he must
> >>> learn dlls becouse dlls are sorta part of practical c..and its real
> nice part (ofc it lacks types
> >>> encoded and call conventions which would allow to just get rid of
> headers - check my thread/post on it)
> >>>
> >>> probably it would allow even normal c to get rid of headers as pif
> everything would just work without headers people just could not include
> them and tha wouldnt break codes
> >> How would that work? To use a function exported from a DLL, you will
> >> need a function signature, perhaps a set of usertypes, enums and
> #defines.
> >>
> >> All the stuff that normally is provided by a header.
> >>
> >> Where would that information come from?
> >>
> >> (My own idea was for an interface info to be embedded inside the DLL,
> >> and accessed by calling a special exported function. For C, that could
> >> just return a string containing the normal header code.
> >>
> >> But it would need cooperation from the people creating the DLL (who
> >> could be writing in any language, not C).
> >>
> >> And from C compilers to delve inside DLL files (and at an early stage
> >> long before linking). Since C compilers can't even shake off
> >> anachronisms like -lm and a.out, I can't see that happening.)
> >>
> >>
> >>
> >> My idea was for my own private use
> > doi
> > lern how PE format works coz it is really important - not mucnh
> pleasant to read but important as hell
> You really don't need to disect a DLL file to extract some data from it.
> A regular interface will do.
>
> For example, for a DLL that exports one function 'add()', add this extra
> function:
>
> char* header = "int add(int, int);\n";
> char* getheader(void) { return header;}
>
> and create a DLL like 'lib.dll'.
>
> Now, in the compiler that wants to import functions from lib.dll, use
> code like this:
>
> #include <stdio.h>
> #include <windows.h>
>
> int main(void) {
> void* handle;
> char* (*fnptr)(void);
>
> handle=LoadLibrary("lib.dll");
> if (handle) {
> fnptr=GetProcAddress(handle, "getheader");
> if (fnptr)
> printf("Header = %s\n", fnptr());
> }
> }
>
> Calling getheader() returns the same string as including a header file
> like 'lib.h'.
>
> No need to be delving inside the PE format.
>
> Actually, as written, that 'header' variable is exported also, so you
> can directly access that, but I prefer to do it via a function.
>
> And, PE is a terrible, terrible format. Only get into as last resort.

you cannot return c code as it must be binary level description language agnostic,
calling code is weird as it imo should be a normal format that you could open on other system then dll is run on
adding a section is normal way and is no specially hard, it is to do in few days (first functioning draft of it, but that would be most work)

On 2023-08-10, Bart <bc@freeuk.com> wrote:
> So, how do you control what functions to export from a .so file?

All global symbols are exported by default; like the would be
in a .a archive, only dynamically.

The way to get control over this is to write a version script

https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html#SEC25

This is given to the linker as another file argument.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

piątek, 11 sierpnia 2023 o 02:30:18 UTC+2 Bart napisał(a):
> And, PE is a terrible, terrible format. Only get into as last resort.

its somewhat bad/slightly terrible imo..could be simpler but binary formats itself are not much pleasant imo
besides its close to internals and many hackers like this kind of internals
(by jackers i rather mean 'internalists')

i think if some understand what it need to contauin it shows it contains what need to contain (like code dump(block), data dump, importd, exports, reallocks and header containing information like cpu/os type and xection properties..
mainly this header could be simplified coz those sections ere needed)

watching this map i dont know the details but roughly it seems
- program begins at 4 MB below is 2 MB stack, dlls are putted down 2 GB
and between program and dlls probably there is heap..some other
regions are also mapped but i dont know what it is

On Thu, 10 Aug 2023 16:15:32 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> What we could have is that an executable just dynamically links to
> functions in these libraries, and the system automatically finds them at
> load time, without the executable having to specify which libraries.

And how is your scheme different than how it already works in the Unix
world ?

> (Symbolic references would have to be fastidiously versioned since
> if multiple versions of a library were installed, the executable would
> not be indicataing which file it wants, other than through the
> names it needs. And also for another reason: clashing names between
> libraries. But the programmer wouldn't see the library and verison
> qualification on the symbol; that's handled transparently by the
> toolchain.)

On 2023-08-11, Spiros Bousbouras <spibou@gmail.com> wrote:
> On Thu, 10 Aug 2023 16:15:32 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> What we could have is that an executable just dynamically links to
>> functions in these libraries, and the system automatically finds them at
>> load time, without the executable having to specify which libraries.
>
> And how is your scheme different than how it already works in the Unix
> world ?

How it differs is that the executable has to nominate the specific
libraries by indicating the library, which came in via the -l option,
and then look for specific symbols from specific libraries that it has
attached.

Under the hood, the semantics is much like dlopen() of specific
liraries to obtain a handle and then doing dlsym(handle, "name")
to look for specific names from specific libs.

Imagine it could specify just symbols, without specifying where
they come from; that's a big difference.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca