Arm64EC – Run x86_64 and Arm code in the same process

Re:Arm64EC – Run x86_64 and Arm code in the same process by zorgmonkey on Monday June 24, 2024 @12:16AM (#40772629)

I'm pretty sure the API you'll want to detect that is IsWow64Process2.

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by szundi on Monday June 24, 2024 @02:44AM (#40773110)

I love the 2s and Exes at the end of Windows API call names

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by formerly_proven on Monday June 24, 2024 @03:15AM (#40773273)

wait/waitid/waitpid/wait3/wait4

dup/dup2/dup3

creat/open/openat/openat2

cough

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by skissane on Monday June 24, 2024 @05:38AM (#40774035)

Even more: clone3, __clone2 (only exists on Itanium), fchmodat2, preadv2, pwritev2, pipe2, sync_file_range2, mmap2 (only certain architectures; for x86, only 32-bit), renameat2, mlock2, faccessat2, epoll_pwait2

My personal prediction is sooner or later we'll see execveat2, to permit setting /proc/PID/comm when using execveat [0].

I doubt we'll ever see clone4, because clone3 is passed a structure argument with the structure size, so new fields can be supported just by increasing the structure size. If other syscalls had done that from the start, much of the 2/3/etc would have been avoided. It is actually a very common practice on Windows (since NT), it has only much more recently been adopted in the Linux kernel

[0] see https://uapi-group.org/kernel-features/

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by phaedrus on Monday June 24, 2024 @12:02PM (#40777702)

I work on a team that supports some equipment related to airplanes. An acronym for one piece of equipment that is decades old is "RCSU". When I got a support call talking about "RSCU", I assumed the person meant "RCSU".

Nope. It turns out, when they made their next-generation piece of equipment, the vendor differentiated it by swapping the inner two letters in an already easy-to-say-wrong acronym.

My reaction was, "WTF didn't they just call it the RCSU2?!"

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by Just_Harry on Monday June 24, 2024 @09:36AM (#40775900)

My favourite is MapViewOfFile3FromApp [0], which is one of the seven variants of MapViewOfFile.

[0]: https://learn.microsoft.com/windows/win32/api/memoryapi/nf-m...

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by orthoxerox on Monday June 24, 2024 @04:34AM (#40773690)

IsWow64Process2ForRealThisTime

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by ale42 on Monday June 24, 2024 @06:07AM (#40774190)

wonder why they didn't call it IsWow64ProcessEx

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by layer8 on Monday June 24, 2024 @01:04PM (#40778428)

The vague convention, as far as I understand, is that Ex denotes an extended variant of a function for more advanced use cases (e.g. with additional parameters/options) which is functionally a superset of the original function, whereas numbered versions are intended to be complete replacements and/or may change the semantics compared to the prior version.

[ Parent | on HN ]

Re:Arm64EC – Run x86_64 and Arm code in the same process by throwaway2037 on Monday June 24, 2024 @11:55PM (#40784318)

I agree.

Examples:

CreateWindowW -> https://learn.microsoft.com/en-us/windows/win32/api/winuser/...

CreateWindowExW -> https://learn.microsoft.com/en-us/windows/win32/api/winuser/...

[ Parent | on HN ]