4 ms·

As I remember it, they were basically the same—but IOKit is C++ (with restrictions) because 3rd party developers didn't want to learn Objective-C. But that's a

As I remember it, they were basically the same—but IOKit is C++ (with restrictions) because 3rd party developers didn't want to learn Objective-C. But that's a hazy, 20 year old memory.

steve1977 6mo ago
From here: https://news.ycombinator.com/item?id=10006411 https://news.ycombinator.com/item?id=10006411 "At some stage in the future we may be able to move IOKit over to a good programming language"
- xenadu02 6mo ago
  IOKit was almost done in Java; C++ was the engineering plan to stop that from happening. Remember: there was a short window of time where everyone thought Java was the future and Java support was featured heavily in some of the early OS X announcements. Also DriverKit's Objective-C model was not the same as userspace. As I recall the compiler resolved all message sends at compile time. It was much less dynamic.
  - pjmlp 6mo ago
    Mostly because they thought Objective-C wasn't going to land well with the Object Pascal / C++ communities, given those were the languages on Mac OS previously. To note that Android Things did indeed use Java for writing drivers, and on Android since Project Treble, and the new userspace driver model since Android 8, that drivers are a mix of C++, Rust and some Java, all talking via Android IPC with the kernel.
    - lukeh 6mo ago
      There was also the Java-like syntax for ObjC but I don’t think that ever shipped.
  - lemoncucumber 6mo ago
    > there was a short window of time where everyone thought Java was the future Makes me think of how plists in macOS are xml because back then xml was the future
spijdar 6mo ago
Yes, you're right! I'm just dolt who's never checked what a .kext on OS X actually is. I had been under the impression that DriverKit drivers were quite a different beast, but they're really not. Here's the layout of a NS ".config" bundle: ./CG6FrameBuffer.config/English.lproj ./CG6FrameBuffer.config/English.lproj/Info.rtf ./CG6FrameBuffer.config/English.lproj/Localizable.strings ./CG6FrameBuffer.config/CG6FrameBuffer_reloc ./CG6FrameBuffer.config/Default.table ./CG6FrameBuffer.config/Display.modes ./CG6FrameBuffer.config/CG6FrameBuffer The driver itself is a Mach-O MH_OBJECT image, flagged with MH_NOUNDEFS. (except for the _reloc images, which are MH_PRELOAD. No clue how these two files relate/interact!) Now, on OS X: ./AirPortAtheros40.kext/Contents ./AirPortAtheros40.kext/Contents/_CodeSignature ./AirPortAtheros40.kext/Contents/_CodeSignature/CodeResources ./AirPortAtheros40.kext/Contents/MacOS ./AirPortAtheros40.kext/Contents/MacOS/AirPortAtheros40 ./AirPortAtheros40.kext/Contents/Info.plist ./AirPortAtheros40.kext/Contents/version.plist OS X added a dedicated image type (MH_KEXT_BUNDLE) and they cleaned up a bit, standardized on plists instead of the "INI-esque" .table files, but yeah, basically the same.
- KerrAvon 6mo ago
  You're focusing on the executable format, which is very much not the driver model.
pjmlp 6mo ago
Yes, also the same reason why Java was originally introduced, Apple was afraid that the developer community educated in Object Pascal / C++, wasn't keen into learning Objective-C. When those fears proved not true, and devs were actually welcoming Objective-C, it was when they dropped Java and the whole Java/Objective-C runtime interop.

As I remember it, they were basically the same—but IOKit is C++ (with restrictions) because 3rd party developers didn't want to learn Objective-C. But that's a hazy, 20 year old memory.

steve1977 6mo ago

From here: https://news.ycombinator.com/item?id=10006411 https://news.ycombinator.com/item?id=10006411 "At some stage in the future we may be able to move IOKit over to a good programming language"

xenadu02 6mo ago
IOKit was almost done in Java; C++ was the engineering plan to stop that from happening. Remember: there was a short window of time where everyone thought Java was the future and Java support was featured heavily in some of the early OS X announcements. Also DriverKit's Objective-C model was not the same as userspace. As I recall the compiler resolved all message sends at compile time. It was much less dynamic.
- pjmlp 6mo ago
  Mostly because they thought Objective-C wasn't going to land well with the Object Pascal / C++ communities, given those were the languages on Mac OS previously. To note that Android Things did indeed use Java for writing drivers, and on Android since Project Treble, and the new userspace driver model since Android 8, that drivers are a mix of C++, Rust and some Java, all talking via Android IPC with the kernel.
  - lukeh 6mo ago
    There was also the Java-like syntax for ObjC but I don’t think that ever shipped.
- lemoncucumber 6mo ago
  > there was a short window of time where everyone thought Java was the future Makes me think of how plists in macOS are xml because back then xml was the future

spijdar 6mo ago

Yes, you're right! I'm just dolt who's never checked what a .kext on OS X actually is. I had been under the impression that DriverKit drivers were quite a different beast, but they're really not. Here's the layout of a NS ".config" bundle: ./CG6FrameBuffer.config/English.lproj ./CG6FrameBuffer.config/English.lproj/Info.rtf ./CG6FrameBuffer.config/English.lproj/Localizable.strings ./CG6FrameBuffer.config/CG6FrameBuffer_reloc ./CG6FrameBuffer.config/Default.table ./CG6FrameBuffer.config/Display.modes ./CG6FrameBuffer.config/CG6FrameBuffer The driver itself is a Mach-O MH_OBJECT image, flagged with MH_NOUNDEFS. (except for the _reloc images, which are MH_PRELOAD. No clue how these two files relate/interact!) Now, on OS X: ./AirPortAtheros40.kext/Contents ./AirPortAtheros40.kext/Contents/_CodeSignature ./AirPortAtheros40.kext/Contents/_CodeSignature/CodeResources ./AirPortAtheros40.kext/Contents/MacOS ./AirPortAtheros40.kext/Contents/MacOS/AirPortAtheros40 ./AirPortAtheros40.kext/Contents/Info.plist ./AirPortAtheros40.kext/Contents/version.plist OS X added a dedicated image type (MH_KEXT_BUNDLE) and they cleaned up a bit, standardized on plists instead of the "INI-esque" .table files, but yeah, basically the same.

KerrAvon 6mo ago
You're focusing on the executable format, which is very much not the driver model.

pjmlp 6mo ago

Yes, also the same reason why Java was originally introduced, Apple was afraid that the developer community educated in Object Pascal / C++, wasn't keen into learning Objective-C. When those fears proved not true, and devs were actually welcoming Objective-C, it was when they dropped Java and the whole Java/Objective-C runtime interop.