5 ms·

I guess you could make the case that windows is written in C++, which is a superset of C which was designed while writing UNIX. Sure the OS is different, but it

by onei 7y ago

I guess you could make the case that windows is written in C++, which is a superset of C which was designed while writing UNIX. Sure the OS is different, but it ended up being built from the same blocks. If we didn't have C, would we have Windows as it is today?

pjmlp 7y ago
Looking back at what Xerox PARC and ETHZ were doing with their workstations, maybe that wouldn't have been much of an issue.
- acqq 7y ago
  Yes the high level language on first Macintoshes was Pascal. Lowest level was assembly. Pascal was not bad at that role, and it would have been possible to develop all the code which was eventually written in C in Pascal too. At least in the dialects that weren’t made just for education.
  - kabdib 7y ago
    Apple's version of Pascal had a lot of non-standard extensions. If you squinted, it was essentially C.
    - pjmlp 7y ago
      So any system programming language with extensions for hardware access were essentially C? Even those 10 years older than C?
      - kragen 7y ago
        Pascal used var parameters rather than pointers into the stack and supported nested subroutines with lexical scope, limiting them to being passed as downward funargs to ensure safety, and it barely missed requiring tag checks on variant record access (an omission Wirth bitterly lamented). Pascal had pointers, but they were strictly for heap-allocated objects, not var parameters or array iteration. In standard Pascal, array size was part of the array type, so you couldn't write functions that operated on arrays of unknown size, because bounds checking of array accesses would have otherwise required passing an additional length word. That's why the string type in TeX is an index into a humongous string pool array. I think this illustrates how the philosophy of Pascal differed from that of C.
        kabdib 7y ago
        These are indeed the places where Apple extended their version of Pascal. C-style calling convention support, pointer arithmetic, much better I/O, and a host of things I can't remember. Suffice to say that when I started working at Apple (towards the end of the Pascal era) I was pretty comfortable, even though I'd been doing mostly C for a long time. This was definitely not the language we had to use in college. (No tagged unions, though. Systems guys are allergic to 'em, apparently). Apple also added object-oriented features, but I don't count those as addressing anything borken or awkward in the base language.
        kragen 7y ago
        Well, in the base language you couldn't store function pointers in variables or record fields, since they might refer to nested subroutines that included a context pointer to their parent subroutine stack frame, and invoking them after it had returned would be catastrophic. This “downward funargs restriction” made OO-style programming in standard Pascal very difficult in a way that it isn't in standard C. So I think the OO features, too, aimed at a weakness of the base language—but I admit I never looked at Apple's version.
        kabdib 7y ago
        Apple's Pascal had function pointers, and I'm pretty sure you could still do callbacks to nested procedures with a little trickery. Ahh, I was right (PDF file here): http://mirror.informatimago.com/next/developer.apple.com/technotes/pt/pdf/pt_31.pdf http://mirror.informatimago.com/next/developer.apple.com/tec... These are not closures, they're still strictly nested and on the native stack, so the usual crashes happen if you execute a callback to something that has gone out of scope. Remind me to tell you about "Fork Queues", a solution we had on the Newton for dealing with multiple entities that all wanted to have the main event loop (of which you could really only ever have one, but we cheated).
        kragen 7y ago
        Oooh, this sounds fantastic!
jng 7y ago
Windows is not written in C++, even if Microsoft did embrace C++ quite a bit with the infamous MFC and so on. Windows was originally written using C and assembly language, using the Pascal calling convention for efficiency. It was originally a layer on top DOS which was written in assembly language. Being a "layer" or not was the subject of a very complex federal antitrust case back in the 90s. You can read "Undocumented DOS" and "Undocumented Windows" for some weird kind of technical investigation thriller which I found weirdly fascinating back in the day.
- pjmlp 7y ago
  Since Windows Vista, Windows has been transitioning to C++, hence why they don't care much more about ISO C beyond of what is required by ISO C++ standard compliance. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_coded_in_c_or_assembler/d4g9we9/ https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...
pjc50 7y ago
I don't think there's anything in the nature of C per se that's required for Windows. Any reasonably low-level compiled language would have done the same job; Pascal is potentially the nearest substitute. Windows had to construct its own executable and library formats anyway.

by onei 7y ago

pjmlp 7y ago

Looking back at what Xerox PARC and ETHZ were doing with their workstations, maybe that wouldn't have been much of an issue.

acqq 7y ago
Yes the high level language on first Macintoshes was Pascal. Lowest level was assembly. Pascal was not bad at that role, and it would have been possible to develop all the code which was eventually written in C in Pascal too. At least in the dialects that weren’t made just for education.
- kabdib 7y ago
  Apple's version of Pascal had a lot of non-standard extensions. If you squinted, it was essentially C.
  - pjmlp 7y ago
    So any system programming language with extensions for hardware access were essentially C? Even those 10 years older than C?
    - kragen 7y ago
      Pascal used var parameters rather than pointers into the stack and supported nested subroutines with lexical scope, limiting them to being passed as downward funargs to ensure safety, and it barely missed requiring tag checks on variant record access (an omission Wirth bitterly lamented). Pascal had pointers, but they were strictly for heap-allocated objects, not var parameters or array iteration. In standard Pascal, array size was part of the array type, so you couldn't write functions that operated on arrays of unknown size, because bounds checking of array accesses would have otherwise required passing an additional length word. That's why the string type in TeX is an index into a humongous string pool array. I think this illustrates how the philosophy of Pascal differed from that of C.
      - kabdib 7y ago
        These are indeed the places where Apple extended their version of Pascal. C-style calling convention support, pointer arithmetic, much better I/O, and a host of things I can't remember. Suffice to say that when I started working at Apple (towards the end of the Pascal era) I was pretty comfortable, even though I'd been doing mostly C for a long time. This was definitely not the language we had to use in college. (No tagged unions, though. Systems guys are allergic to 'em, apparently). Apple also added object-oriented features, but I don't count those as addressing anything borken or awkward in the base language.
        kragen 7y ago
        Well, in the base language you couldn't store function pointers in variables or record fields, since they might refer to nested subroutines that included a context pointer to their parent subroutine stack frame, and invoking them after it had returned would be catastrophic. This “downward funargs restriction” made OO-style programming in standard Pascal very difficult in a way that it isn't in standard C. So I think the OO features, too, aimed at a weakness of the base language—but I admit I never looked at Apple's version.
        kabdib 7y ago
        Apple's Pascal had function pointers, and I'm pretty sure you could still do callbacks to nested procedures with a little trickery. Ahh, I was right (PDF file here): http://mirror.informatimago.com/next/developer.apple.com/technotes/pt/pdf/pt_31.pdf http://mirror.informatimago.com/next/developer.apple.com/tec... These are not closures, they're still strictly nested and on the native stack, so the usual crashes happen if you execute a callback to something that has gone out of scope. Remind me to tell you about "Fork Queues", a solution we had on the Newton for dealing with multiple entities that all wanted to have the main event loop (of which you could really only ever have one, but we cheated).
        kragen 7y ago
        Oooh, this sounds fantastic!

jng 7y ago

Windows is not written in C++, even if Microsoft did embrace C++ quite a bit with the infamous MFC and so on. Windows was originally written using C and assembly language, using the Pascal calling convention for efficiency. It was originally a layer on top DOS which was written in assembly language. Being a "layer" or not was the subject of a very complex federal antitrust case back in the 90s. You can read "Undocumented DOS" and "Undocumented Windows" for some weird kind of technical investigation thriller which I found weirdly fascinating back in the day.

pjmlp 7y ago
Since Windows Vista, Windows has been transitioning to C++, hence why they don't care much more about ISO C beyond of what is required by ISO C++ standard compliance. https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/ https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an... https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_coded_in_c_or_assembler/d4g9we9/ https://www.reddit.com/r/cpp/comments/4oruo1/windows_10_code...

pjc50 7y ago

I don't think there's anything in the nature of C per se that's required for Windows. Any reasonably low-level compiled language would have done the same job; Pascal is potentially the nearest substitute. Windows had to construct its own executable and library formats anyway.