nitpicks about os HOT 8 CLOSED

Lots to respond to here, let me try and tackle it. Edit- I don't know why github keeps renumbering things, I'm not a Markdown pro. Sorry.

1. The goal behind typedefing the basic types is to enable changing them if we need to. LONG/ULONG are always 32-bits, (U)LONGLONG is always 64, (U)SHORT is 16, (U)INTN is the native integer size. This should be better documented. INT is probably the most ill-defined one, as it currently typedefs to int, and often converts to and from C library interfaces which have to be the non-typedefed int. We use that one the least.
2. You're right, there may be a bug there, as those types are usually, but not always (eg ARM) signed.
3. You're right, that was an early bad habit that I've recently started working to correct of not adding const to things. There's a PCSTR and PCVOID for const char * and const void *, and we're working towards replacing those where appropriate. Patches appreciated.
4. A combination of paranoia and messiness, regrettably. I think passing along the string size is safer, and will be working towards that.
5. I'm not totally sure what you mean by spawning it from scratch. There is a PsCreateProcess up in the kernel that directly creates a process. We currently only use that for creating the init process. Generally fork+exec would be slower than PsCreateProcess because fork has the added overhead of copying all the page tables and address space, only to have that all be thrown away when the exec happens. There is a vfork system call that we have not yet implemented that was designed specifically to mitigate those issues. We want to add support for that, but it comes with some caveats that make it tricky for applications to use correctly.
6. It is not our intention to infect user applications that compile using our C library headers with the GPL. I'm not a lawyer, so I'm not sure whether or not the System Library Exception of the GPL helps here. Perhaps we should consider changing the C library headers to LGPL.

from os.

1. c long flip flops its size on posix and it's an important pitfall, so it may be a surprise for linux programmers as they are usually ignorant about windows conventions, INT is probably a better choice here;
2. wchar is probably never signed? AFAIK, unicode uses only positive values.
3. man pages say posix removed vfork in favor of posix_spawn, how about it? fork is not easy to use either as it predates multithreading;
4. looks like the purpose of System Library Exception is that a GPL-covered application doesn't supply sources of the system library, see also case of linux - needed a link exception for GPL libraries, and LGPL has requirements; there's also a belief that headers are not worth protecting, so boost license would resolve some questions in this case for good, it also allows sublicensing later if needed.

from os.

1. Yes, I learned this about long after getting started. It would probably be better to use more explicit typedefs with "32" and "64" in the name somewhere. Not sure whether the churn is worth it though. At the very least there should be a comment near the typedef of LONG/ULONG.
2. On my random Ubuntu machine, I believe wchar is a (signed) int, probably as an analog to char:

evan@mbuild:/usr/include$ echo | gcc -dM -E - | grep WCHAR
#define __WCHAR_MAX__ 2147483647
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __WCHAR_TYPE__ int
#define __SIZEOF_WCHAR_T__ 4

1. I believe everyone implements posix_spawn as a C library function, and uses either fork or vfork when calling up to the kernel. My understanding is the purpose of posix_spawn is basically to paper over fork/vfork+exec, for implementations that might not support fork, like MMU-less systems. So I think either way, to get the perf bump associated with not forking, we're stuck building vfork.
2. I think I agree this issue needs consideration. Probably LGPL for the headers plus a link exception for the user mode libraries.

from os.

I've done a first pass at converting PSTR to PCSTR on the kernel components at the API level. I can submit a PR if that might be useful.

from os.

1. the range for UTF-32 char is [0,0x10ffff] - never negative, which is not the case for UTF-16 code unit.
2. vfork predates posix_spawn, that's why implementation as a library, but if minoca provides posix_spawn (or its most useful subset) as a kernel function (and have freedom to optimize it), it wouldn't need to provide vfork at all unless you want to support vfork specifically.

from os.

1. I think the signedness of the wchar type is tied to the compiler. When someone does L"string" the compiler has a specific type for that pointer. If our definition of wchar_t didn't match the compiler, then things like wmemchr(L"abc", L'b', 3) wouldn't compile properly.

2. Yes, we could think about supporting posix_spawn specifically as a system call rather than vfork. What makes me hesitate is that it ties types like posix_spawn_file_actions_t and posix_spawnattr_t in with the kernel. The kernel and C library need to agree on these types, and then the kernel needs to implement its functionality, which could have otherwise been implemented as library calls. Additionally, if more posix_spawnattr_* or posix_spawn_file_actions_* functions are added, these will require coordinating kernel/library changes, rather than just library changes. On the other hand, the benefit to performance might be worth it, as you could save yourself the overhead of several system calls if a lot of these attributes are set. I wonder on average how many attributes and/or file actions are set for a workload that uses posix_spawn heavily?

from os.

Any update on the licensing? I think it would be best for headers/libraries to be licensed under the LGPL v2.1, as it is compatible with both the GPL v2 and v3.

from os.

Done with 1f3cdf5 . Thanks for the prod on this one.

from os.