
C#88: The Original C# (2018) - cpeterso
https://medium.com/@ricomariani/c-88-the-original-c-66a1b5de47d7
======
hestefisk
Never heard of this. Very interesting. Fun fact: C# was originally called
‘Cool’ internally in MS before the MS marketing took over and rebranded
everything Visual X this or X .Net that. Who doesn’t remember Windows Server
.Net (later rebranded to 2003), which did not have a single line of CLR code
in it apart from the standard runtime?

~~~
mschaef
A lot of this line of work also originated from efforts to solve problems in
COM, which was becoming central to Microsoft's approach to platforms. The idea
was to make it easier to produce objects in different languages and then let
them interoperate at runtime. In that regard, Microsoft's notion of a common
runtime environment for objects was a natural follow on to COM's concept of
objects abstracted behind interfaces.

There was also a great deal of confusion around the way Microsoft originally
introduced COM. When Windows 3.1 came out, one of its marquee features was
something called OLE 1.0 - Object Linking and Embedding. This was a composite
document approach built on an early technology called DDE, Dynamic Data
Exchange. (Which was brittle, and based on Windows messaging.) A few years
later, they introduced OLE 2.0, which added a bunch of features, but mainly
completely replaced DDE with COM. For a while, there was a lot of conflation
of COM as something OLE 2.0 specific.

~~~
sebazzz
Wasn't the framework itself originally called COM+? The environment variable
tweak knobs still carry the prefix "ComPlus_"

~~~
mschaef
You may be thinking of COR, for "Common Object Runtime", which was formerly
known as COM 3.0.

[http://www.danielmoth.com/Blog/mscorlibdll.aspx](http://www.danielmoth.com/Blog/mscorlibdll.aspx)

------
adzm
This appears to have mostly the # in common with C#, since this is mostly an
extension of C, like C++ or Objective-C etc.

------
james_s_tayler
Is this related to C# having this structure where everything is split into
hundreds of csproj files and multiple solutions?

And this must be related to needing to have pdb file or being unable to debug.

I wish those two things were not the case. And nuget.

I find C# wonderful except those particular decisions give me pain on a daily
basis.

~~~
jaabe
I think splitting into projects with their own separate dependencies is/was
actually one of the few advantages to C#, because it lets you replace an
entire project and it’s dependencies seamlessly.

This has been extremely handy for us as we’ve been slowly upgrading to .net
core. Because we can literally do it one project at a time without even
risking breaking anything. Before going to .Net core it made switching from
Web Forns to MVC really, really painless because all the business logic lived
in its own projects, allowing us to run and maintain the Web Forms project,
while building its replacement within the same solution.

I guess it requires you to think about the architecture of your solution, but
what stack doesn’t? I say “is/was” an advantage though, because it’s primary
use cases are frankly mostly related to the past or really bad practices. It
allows you to keep a single project running on some really old .Net version,
to utilise something legacy. That’s bad, but sometimes it has real works
value, even if it’s bad.

NUGET has been fairly terrible though, and despite its many improvements,
frankly continues to be so.

~~~
stult
My experience has been the same. It's great when the code base is designed and
maintained by people who view assemblies as isolated, fully separable
entities. But many programmers walk into dotnet not understanding the approach
and make a mess of it.

~~~
james_s_tayler
It's for exactly this reason that I think anything that makes the
_technically_ optimal set of choices is actually a bad bet because the
probability it is understood well enough to be used in the correct manner is
low and it's possible to use it an an incorrect manner. So that's mostly what
you see.

~~~
jaabe
I don’t understand that though. I agree that C# certainly could be clearer on
the intended purpose of project separation, maybe it could even be stricter,
but the default way to build projects in C# is with a high amount of
isolation. You can break this isolation, but you have to deviate from the
standard. Hell breaking some parts of the project isolation in C# is even
quite tricky.

Ironically consolidating your packages cross projects while using NUGET is
suggested by standard, but I’ve already shared my views on NUGET being
terrible.

Anyway, my point goes something like, if you’re not utilising OOP “correctly”
in C#, then why would you be using OOP “correctly” in a language that is even
less opinionated about isolation than C#?

I say “correctly” in quotes because I personally like a high amount of
isolation in my OOP, but I’m sure not every one does.

------
tomcam
Fascinating. I worked in the developer tools division when the .net of C# was
released and had no idea this was part of it is true.

------
mhd
> The compiler produced hybrid PCode and native x86 assembly, traditional for
> MS applications at the time.

P-Code? As in UCSD Pascal?

~~~
reacweb
Yes, Microsoft basic is very fundamental in understanding the growth of
Microsoft. Visual basic was generating pcode and I was told that many office
applications (on windows 3.1) were 90% pcode and 10% assembly. The developers
were writing pcode directly.

~~~
mschaef
Microsoft's use of pcode in BASIC predates even Visual Basic. I believe the
first use of it was in QuickBASIC 4.0 (~87-88), which had an adversing
campaign built around the fact it could compile at some ridiculously high
rate.

What was happening, however, was that part of the compilation process was
built into the editor and run incrementally. When you typed in and completed a
line of code, it would be shipped off to the compiler, analyzed for errors,
and then represented in the editor. This was easiest to see in the fact that
the editor would automatically capitalize keywords, but also visible in the
fact it would immediately report certain kinds of errors and make other minor
code corrections. Heady stuff in 1988 when running at 4.77MHz. (The same was
true for the interactive debugging tools built into the IDE.)

In any event, this was the precursor for similar functionality in later
products, ranging from MS BASIC 7.0 to the Visual BASIC series.

BASIC 7.0 was also interesting in that it was at the tail end of Microsoft's
BASCOM product line for DOS. For years, they'd offered a BASIC compiler
product in parallel with the interpreted products that got most of the press
ant attention. The compiler product was what you used if your interpreted
BASIC program needed more execution speed or better packaging. It was BASIC 7
where the QuickBASIC IDE officially converged with the full machine code
compiler. BASIC 7 included the IDE, a full compiler that could also target
OS/2, and an ISAM database library. It was really a precursor to all the uses
of VB to build line of business apps, etc.

> I was told that many office applications (on windows 3.1) were 90% pcode and
> 10% assembly.

The C compiler (at least) had options for compiling C into pCode that would be
interpreted at runtime. I've forgotten most of the details other than that it
was mainly sold as a code compression scheme of sorts. This was on the
observation that pCode was more compact, but slower. (The pCode and the
interpreter itself were all bundled into an x86-specific binary file, so there
was no pretense of any of the cross-platform aspirations commonly associated
with pCode.)

~~~
scarface74
Microsoft was writing BASIC interpreters for early 8 but computers. The
original AppleSoft Basic built into Apple II’s in the early 80s was written by
MS.

~~~
mschaef
Yup. They were founded on a BASIC for the Altair 8800. pCode as an
architectural element of their BASICS, however, was ten or more years after
that. (IIRC, Applesoft BASIC's execution model was a doubly linked list of
statement structures. My guess is tokenized, but not in the same sense as QB4
compiled to pcode.)

~~~
scarface74
I don’t remember them being a double link list. IIRC, the first two bytes of a
tokenized line was the address of the next statement and each command was
tokenized.

For speed, if you had a “subroutine” (gosub/return) that was called
frequently, it was better to place it at the beginning of the program because
it was an O(n) operation to travel the linked list.

It makes me sad thinking about how much more I knew about the underpinnings of
my computer architecture and chosen language in the 8th grade than I know now
as a working professional. I can still write 65C02 assembly language using an
Apple // emulator but I wouldn’t know where to start with x86.

~~~
mschaef
> I don’t remember them being a double link list. IIRC, the first two bytes of
> a tokenized line was the address of the next statement and each command was
> tokenized.

You may well be right... it's been a longer time than I care to admit.

> I can still write 65C02 assembly language using an Apple // emulator but I
> wouldn’t know where to start with x86.

My job out of school was at least partially to write software for an embedded
4MHz 80188... not too different from an original PC. Even in such a limited
environment, virtually everything was written in C. This includes things like
interrupt handlers directly invoked by the CPU and task switching code in our
primitive RTOS. I think the only assembler was a bit of startup code.

> It makes me sad thinking about how much more I knew about the underpinnings
> of my computer architecture...

I see your point, but my view is that the goal of many of the abstractions we
have is to make it possible to shift our focus to higher level and presumably
more important concerns. It doesn't always work out that way, of course -
sometimes the abstractions get in the way - but I do miss the power of today's
languages when I go back to lower level tooling.

One side note to this is that the embedded project above started out running
in real mode X86, but by the time I'd left, we had ports for 32-bit protected
mode, MC68K, and a version hosted Win32. There were sound technical and
commercial reasons for all of this, but it all would have been a lot more
costly to achieve in time and money if we'd been coding in assembler. In other
words, we arguably gained by not knowing more about the underpinnings of our
computer.

------
garganzol
Always wondered why .PDB is such a strange format. Several interlaced streams
of data, all going in parallel. Now I know.

By the way, .XBF (XAML Binary Format, used in UWP apps) has a similar
skeleton. So the heritage of C#88 lives on.

~~~
rmariani
The interleaved page strategy has lots of benefits...

------
estomagordo
I had no idea C#88 was a thing. Thanks for sharing.

~~~
misterman0
In 1988 a Commodore 64 was still a thing. It ran Microsoft Basic. And .Net was
slowly being built. Bill Gates has some wild ideas.

~~~
nurettin
I had a C= 64, but didn't know it ran Microsoft Basic. All I saw was "all
rights reserved" and "32kb ram ready".

~~~
nurettin
apparently you can run the following on a commodore shell for a Microsoft
easter egg:

    
    
        WAIT 6502,0

~~~
misterman0
Unfortunately that command is not supported in [0]. What does it do?

[0] [https://virtualconsoles.com/online-
emulators/c64/](https://virtualconsoles.com/online-emulators/c64/)

~~~
dangerbird2
It seems like it was only in Commodore PET Basic. It would print `MICROSOFT!`

[https://www.c64-wiki.com/wiki/Microsoft#Easter_Egg_.28Micros...](https://www.c64-wiki.com/wiki/Microsoft#Easter_Egg_.28Microsoft.21.29)

------
rmariani
Note this nothing to do with C# of the .net world except the name.

C#88 inspired thoughts but its code basically died in 88.

------
register
> a variant of the C language designed for incremental compilation

This is extremely interesting per se and I wonder why it didn't catch up. Is
there anything similar available today? It would be interesting to know more
about the original syntax of C#88.

------
msla
This seems like an April Fool's joke.

The complete lack of any other information is suspicious.

~~~
Zanni
It's real. I was at Microsoft from 1986-1991, working on Windows (2 and 3). We
heard frequent stories of this C#, exactly as described, but never got our
hands on it.

~~~
mschaef
> I was at Microsoft from 1986-1991, working on Windows (2 and 3)

What was that like? What parts did you work on?

(And thank you... I cut my teeth on Windows 3 in particular and learned a lot,
I am sure, from code you helped contribute to.)

