5 ms·

Back in 1997 I was a developer on a commercial Windows game, written in Turbo Pascal (or technically, Borland Pascal). Not sure how many games have been develop

Back in 1997 I was a developer on a commercial Windows game, written in Turbo Pascal (or technically, Borland Pascal). Not sure how many games have been developed with Turbo; can't be that many. We had to write our own bindings for DirectDraw and DirectSound, since there were no C header files we could use directly. (This was before 3D acceleration, so no Direct3D, which wouldn't really have been feasible.) We were all Pascal programmers at the time, and didn't even consider using C or C++. Turbo Pascal was really ideal for writing games in. Short develop-compile-debug cycle, great native performance, support for inline assembly (our image code had lots of this), and easy calling into C libs. I was using Borland's Pascal tools as late as 1999-2000, the last iteration being Delphi 4.0. While I did plenty of GUI stuff, my biggest project was a non-GUI teleconferencing solution that consisted of a web application that orchestrated calls using several distributed backends (or microservices as we would call them today), with RPC using Microsoft DCOM; Delphi had very good COM support. As part of this app, I had to talk to several low-level telecomms boards by Dialogic, which of course only had C headers. I wrote an AST-based C-to-Pascal translator so I didn't have to do all the headers manually, and I was able to use it to translate things like Microsoft's MAPI headers, which were COM. Still... It's amazing to think today that I was so fond of/productive in Pascal that I shoehorned everything into it, even those headless server apps, when obviously C or C++ would have provided much less friction. The answer is of course that TP/BP/Delphi all provided an amazingly productive experience. These days I use Go a lot, which of course is heavily influenced by the Wirth family of languages. Go today feels a lot like Borland Pascal with garbage collection. </nostalgia>

vram22 10y ago
Great anecdote, thanks for sharing. Got to agree on the productivity part. I did just part of one product in Turbo Pascal (just at the start of my career), which was a freelance project, interestingly, without any previous job experience, like some others here have said they did, but also a lot of personal / fun stuff with it, and also taught it for a while in a training institute. Most of my other product and project work was / is done in C, Java, Ruby, Python etc. But as I too have said here a few times before, never come across a more productive environment than TP and Delphi - though Python is close, for the language part alone (leaving aside libs, GUI, building, etc.).
pacaro 10y ago
Why no c header files? I was writing against DirectDraw and DirectSound in that time frame using C, so I'm assuming that there were headers. Or did you just not have access to the windows SDK?
- lobster_johnson 10y ago
  We had the C header files, but Turbo/Borland Pascal could not read them, it being a different language and all. You had to translate them into Pascal and declare each imported function as something like: function DirectDrawCreate(...): HRESULT; stdcall; external 'ddraw.dll';
  - clouddrover 10y ago
    Rudy Velthuis has a great article on the problems commonly encountered when converting C headers to Pascal (or more specifically Delphi): http://rvelthuis.de/articles/articles-convert.html http://rvelthuis.de/articles/articles-convert.html
    - lobster_johnson 10y ago
      Yep. As I said in a previous comment, I actually released a tool, called htrans, to do this, which worked very well for a lot of people. It was a hand-coded C parser with support for a minimal subset of C++ concepts, needed to successfully translate COM interfaces. It had a bunch of kludges specifically to recognize COM. Handling macros was without doubt the most painful part of it, because I couldn't just run the .h file through a preprocessor; I had to also preserve the macros and try to convert them into declarations, so that "#define FOO 1" would result in "const FOO: Integer = 1;" or whatever. Not too bad with simple things, but sometimes people will abuse macros to declare functions... htrans worked well enough that I could run it on a bunch of stuff and not need to edit the resulting .pas files at all. Unfortunately, I suspect I've lost the source code.
  - pacaro 10y ago
    Thanks for the clarification. All of this not being helped by the weird macros COM headers used to work in both C and C++ I'm not sure whether I have nostalgia for that time or Stockholm syndrome

vram22 10y ago

Great anecdote, thanks for sharing. Got to agree on the productivity part. I did just part of one product in Turbo Pascal (just at the start of my career), which was a freelance project, interestingly, without any previous job experience, like some others here have said they did, but also a lot of personal / fun stuff with it, and also taught it for a while in a training institute. Most of my other product and project work was / is done in C, Java, Ruby, Python etc. But as I too have said here a few times before, never come across a more productive environment than TP and Delphi - though Python is close, for the language part alone (leaving aside libs, GUI, building, etc.).

pacaro 10y ago

Why no c header files? I was writing against DirectDraw and DirectSound in that time frame using C, so I'm assuming that there were headers. Or did you just not have access to the windows SDK?

lobster_johnson 10y ago
We had the C header files, but Turbo/Borland Pascal could not read them, it being a different language and all. You had to translate them into Pascal and declare each imported function as something like: function DirectDrawCreate(...): HRESULT; stdcall; external 'ddraw.dll';
- clouddrover 10y ago
  Rudy Velthuis has a great article on the problems commonly encountered when converting C headers to Pascal (or more specifically Delphi): http://rvelthuis.de/articles/articles-convert.html http://rvelthuis.de/articles/articles-convert.html
  - lobster_johnson 10y ago
    Yep. As I said in a previous comment, I actually released a tool, called htrans, to do this, which worked very well for a lot of people. It was a hand-coded C parser with support for a minimal subset of C++ concepts, needed to successfully translate COM interfaces. It had a bunch of kludges specifically to recognize COM. Handling macros was without doubt the most painful part of it, because I couldn't just run the .h file through a preprocessor; I had to also preserve the macros and try to convert them into declarations, so that "#define FOO 1" would result in "const FOO: Integer = 1;" or whatever. Not too bad with simple things, but sometimes people will abuse macros to declare functions... htrans worked well enough that I could run it on a bunch of stuff and not need to edit the resulting .pas files at all. Unfortunately, I suspect I've lost the source code.
- pacaro 10y ago
  Thanks for the clarification. All of this not being helped by the weird macros COM headers used to work in both C and C++ I'm not sure whether I have nostalgia for that time or Stockholm syndrome