The Journey Before main() • Hacker News Board

Re: The Journey Before main()

#11

Post by AnimalMuppet » Sat, Oct 25, 2025, 9:08 PM UTC

forrestthewoods wrote: post #6

vbezhenar wrote: post #3

I wonder how many C projects prefer to avoid standard library, just invoking Linux syscalls directly. Much more fun to write software this way, IMO.

You had me with “avoid C standard library” but lost me at “incoming Linux syscalls directly”. Windows support is a requirement, and no WSL2 doesn’t count. C standard library is pretty bad and it’d be great if not using it was a little easier and more common.

> Windows support is a requirement...

For what?

There is some software for which Windows support is required. There are others for which it is not, and never will be. (And for an article about running ELF files on RiscV with a Linux OS, the "Windows support" complaint seems a bit odd...)

Re: The Journey Before main()

#12

Post by jjmarr » Sat, Oct 25, 2025, 9:09 PM UTC

vbezhenar wrote: post #3

I wonder how many C projects prefer to avoid standard library, just invoking Linux syscalls directly. Much more fun to write software this way, IMO.

Tons of driver code does this.

Re: The Journey Before main()

#13

Post by LegionMammal978 » Sat, Oct 25, 2025, 9:11 PM UTC

gpm wrote: post #9

pmc00 wrote: post #8

Earlier quoted context omitted.

You can do this in Windows too, useful if you want tiny executables that use minimum resources. I wrote this little systemwide mute utility for Windows that way, annoying to be missing some parts of the CRT but not bad, code here: https://github.com/pablocastro/minimute

I thought windows had an unstable syscall interface?

It looks like that project does link against the usual Windows DLLs, it just doesn't use a static or dynamic C runtime.

Re: The Journey Before main()

#14

Post by itopaloglu83 » Sat, Oct 25, 2025, 9:16 PM UTC

I like doing this with old microcontrollers like PIC16 series etc. You said see how to stack pointer, timers, and variables etc. all are configured.

Re: The Journey Before main()

#15

Post by mscdex » Sat, Oct 25, 2025, 9:17 PM UTC

khaledh wrote: post #7

> A note on interpreters: If the executable file starts with a shebang (#!), the kernel will use the shebang-specified interpreter to run the program. For example, #!/usr/bin/python3 will run the program using the Python interpreter, #!/bin/bash will run the program using the Bash shell, etc. This caused me a lot of pain while trying to debug a 3rd party Java application that was trying to launch an executable script…

Also be aware that kernel support for shebangs depends on CONFIG_BINFMT_SCRIPT=y being in the kernel config.

Re: The Journey Before main()

#16

Post by throwawaysoxjje » Sat, Oct 25, 2025, 9:18 PM UTC

forrestthewoods wrote: post #6

vbezhenar wrote: post #3

I wonder how many C projects prefer to avoid standard library, just invoking Linux syscalls directly. Much more fun to write software this way, IMO.

You had me with “avoid C standard library” but lost me at “incoming Linux syscalls directly”. Windows support is a requirement, and no WSL2 doesn’t count. C standard library is pretty bad and it’d be great if not using it was a little easier and more common.

A requirement from whom? To do what?

Re: The Journey Before main()

#17

Post by pmc00 » Sat, Oct 25, 2025, 9:23 PM UTC

LegionMammal978 wrote: post #13

gpm wrote: post #9

Earlier quoted context omitted.

I thought windows had an unstable syscall interface?

It looks like that project does link against the usual Windows DLLs, it just doesn't use a static or dynamic C runtime.

Windows isn’t quite like Linux in that typically apps don’t make syscalls directly. Maybe you could say what’s in ntdll is the system call contract, but in practice you call the subsystem specific API, typically the Win32 API, which is huge compared to the Linux syscall list because it includes all sorts of things like UI, COM (!), etc.

The project has some of the properties discussed above such as not having a typical main() (or winmain), because there’s no CRT to call it.

Re: The Journey Before main()

#18

Post by 1718627440 » Sat, Oct 25, 2025, 9:25 PM UTC

vbezhenar wrote: post #3

I wonder how many C projects prefer to avoid standard library, just invoking Linux syscalls directly. Much more fun to write software this way, IMO.

I generally try to stay portable, but file descriptors are just to nice, to not use them.

Re: The Journey Before main()

#19

Post by 1718627440 » Sat, Oct 25, 2025, 9:28 PM UTC

khaledh wrote: post #7

> A note on interpreters: If the executable file starts with a shebang (#!), the kernel will use the shebang-specified interpreter to run the program. For example, #!/usr/bin/python3 will run the program using the Python interpreter, #!/bin/bash will run the program using the Bash shell, etc. This caused me a lot of pain while trying to debug a 3rd party Java application that was trying to launch an executable script…

Note, that this is not a Java specific problem, it can occur with other programs as well. "No such file or directory" is just the nice description for ENOENT, which can occur in a lot of syscalls. I typically just run the program through strace, then you will quickly see what the program did.

Re: The Journey Before main()

#20

Post by gjf » Sat, Oct 25, 2025, 9:28 PM UTC

khaledh wrote: post #7

> A note on interpreters: If the executable file starts with a shebang (#!), the kernel will use the shebang-specified interpreter to run the program. For example, #!/usr/bin/python3 will run the program using the Python interpreter, #!/bin/bash will run the program using the Bash shell, etc. This caused me a lot of pain while trying to debug a 3rd party Java application that was trying to launch an executable script…

For those interested, I did a breakdown of the hashbang: https://blog.foletta.net/post/2021-04-19-what-the/