Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Journey Before main()

amit.prasad.me

Post reply on HN
Print view View original

141–145 of 145 posts

Re: The Journey Before main()

#141

Post by forrestthewoods »

1718627440 wrote: post #137
forrestthewoods wrote: post #125

Earlier quoted context omitted.

> Microsoft completely lacks POSIX tools True! > compiler needs to have a complete IDE installed Not true. You can download just MSVC the toolchain sans IDE. Works great. https://stackoverflow.com/questions/76792904/how-to-install-... > compiler invocation also doesn't really correspond to any other compiler True. But you don’t have to use MSVC. You can just use Clang for everything. Clang on Windows does typically u…

> Not true. You can download just MSVC the toolchain sans IDE. Works great. How is the standalone MS build system called?

The standalone IDE-less build tools comes with MsBuild.exe. So you just use that.

Re: The Journey Before main()

#142

Post by forrestthewoods »

1718627440 wrote: post #134
forrestthewoods wrote: post #125

Earlier quoted context omitted.

> Microsoft completely lacks POSIX tools True! > compiler needs to have a complete IDE installed Not true. You can download just MSVC the toolchain sans IDE. Works great. https://stackoverflow.com/questions/76792904/how-to-install-... > compiler invocation also doesn't really correspond to any other compiler True. But you don’t have to use MSVC. You can just use Clang for everything. Clang on Windows does typically u…

But then I don't understand your complaints against MSYS2/MinGW. MSYS2 UCRT (the default environment) is a collection of POSIX tools and GCC to compile against the Microsoft C++ standard library. The only difference to what you tell me is completely fine is, that it uses GCC instead of Clang. Other MSYS2 environments are Clang instead of GCC. MinGW is the open-source implementation of the Windows API, so that you can…

Using MinGW and POSIX tools is trying to force a square Linux peg through a round Windows hole. You can try and force it if you want.

If you started with a native Windows-only project you would never use MinGW. Probably 0.01% of Windows projects use GCC.

Over the years I have come to associate “project uses MinGW” with “this probably take two days of my life to get running and I’m just going to hit hurdle after hurdle after hurdle”.

The whole Linux concept of a “dev environment” is kind of really bad and broken and is why everyone uses Docker or Linux or one of a dozen different mutually incompatible environments.

The actually correct thing to do is for projects to include their fucking dependencies so they JustWork without jumping through all these hoops.

Re: The Journey Before main()

#143

Post by forrestthewoods »

1718627440 wrote: post #132
forrestthewoods wrote: post #130

Earlier quoted context omitted.

> Treat static/dynamic linking the same Imagine you have an executable with a random library that has a global variable. Now you have a shared/dynamic library that just so happens to use that library deep in its bowels. It's not in the public API, it's an implementation detail. Is the global variable shared across the exe and shared lib or not? On Linux it's shared, on Windows its not. I think the Windows way is bett…

> On Linux it's shared, on Windows its not. Yes, the default compiler invocation makes all symbols exported. But leaving it like that is super lazy, it will likely break things (like you wrote). You can change the default with -fvisibility=[default|internal|hidden|protected] and it's kind of expected that you do. Oh, and I just found out that GCC has -fvisibility-ms-compat, to make it work like the MS compiler. > Ins…

> You can change the default

My unfortunate experience is that changing the default just breaks other things.

I really blame C++ as the root evil. This type of behavior really really ought to be part of the language spec. It’s super weird that it’s not.

> How is [foo.imp.lib] file created?

When the DLL is compiled

> I don't really see the benefit of linking against foo2.15.imp.lib compared to foo2.15.dll

The short version is “because the whole file isn’t actually necessary”.

Zig moves mountains to make cross-compiling possible. Linux is BY FAR the hardest platform to crosscompile for. macOS and Linuxate trivial. Linux it’s alllllmost impossible. Part of their trick to make it possible is to generate stub .so files which are effectively import libs. Which is what should have been used all along! https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

> When you link against a symbol that was last changed in 2.15, you link against glibc2.15, not against glibc2.40. If you only use symbols from glibc2.15, then you have effectively linked the complete program against glibc2.15.

It really really needs to be explicit. It’s otherwise impossible to control. And hard to understand where a newer symbol is coming from.

> on Windows you put the libraries into 'C:\Program Files\PROGRAM\'

It is relatively rare for a program in Program Files to add itself to the PATH.

> they should have at least the decency to roll it in /opt

I think folders like /opt and /usr/lib are pure evil. Programs should include their %{#^]{}^]+}*}^ dependencies.

uv solves a lot of the Python problems. Every project gets to define its own version of Python and own collection of libraries with whatever god forsaken version resolution. Having /usr/lib/python3.x is a failure state.

Re: The Journey Before main()

#144

Post by rfl890 »

matheusmoreira wrote: post #139
rfl890 wrote: post #113

Earlier quoted context omitted.

Kernel32.dll is loaded into all Windows processes by default, so you actually can have a valid, working Windows binary with 0 entries in the import table. See here[1] for a "Hello world" program written as such. [1]: https://gist.github.com/rfl890/195307136c7216cf243f7594832f4...

That's interesting. How does it work? PEB *peb = (PEB *)__readgsqword(0x60); LIST_ENTRY *current_entry = peb->Ldr->InMemoryOrderModuleList.Flink->Flink; It just obtains a pointer to the loader's data structures out of nowhere? Is this actually supported by Microsoft or are people going to end up in a Raymond Chen article if they use this?

It's in no way supported by Microsoft (and is flagged by most anti-viruses), it was just to demonstrate that kernel32.dll is available for "free" in all programs. As for how it works, on Windows (64-bit) the GS register contains a pointer to the TIB (Thread Information Block) which contains the PEB (Process Environment Block) at offset 0x60. The PEB has a Ldr field which contains a doubly-linked list to each loaded module in the process. From here I obtain the requested module's base address (here kernel32.dll), parse the PE headers to find the function's address and return it.

Re: The Journey Before main()

#145

Post by matheusmoreira »

rfl890 wrote: post #144
matheusmoreira wrote: post #139

Earlier quoted context omitted.

That's interesting. How does it work? PEB *peb = (PEB *)__readgsqword(0x60); LIST_ENTRY *current_entry = peb->Ldr->InMemoryOrderModuleList.Flink->Flink; It just obtains a pointer to the loader's data structures out of nowhere? Is this actually supported by Microsoft or are people going to end up in a Raymond Chen article if they use this?

It's in no way supported by Microsoft (and is flagged by most anti-viruses), it was just to demonstrate that kernel32.dll is available for "free" in all programs. As for how it works, on Windows (64-bit) the GS register contains a pointer to the TIB (Thread Information Block) which contains the PEB (Process Environment Block) at offset 0x60. The PEB has a Ldr field which contains a doubly-linked list to each loaded m…

That's actually amazing. Similar to the way Linux's vDSO is used. I'm disappointed that it's not supported and regarded as suspicious...
Post reply on HN