ITKarma picture

Electronic Arts opened the source code for the first Command & amp; Conquer , as well as Command & amp; Conqueror: Red Alert . You can download it from GitHub .

All content is licensed GPL v3 ; in addition, all comments are saved in the source code. Only the changelog used in the development of the version control system is missing. Everything seems to have just been uploaded to Git recently.

I decided to study what was going on inside this game engine. I will not describe each line of code, but at least it will be interesting to take a look at what C++ development was like in the early 1990s.

We will only study the source code “Command & amp; Conquer: Red Alert "because it looks like a fork of the first game. In the repository, it is located in the CDMY0CDMY folder.


  1. 290 C++ Header Files
  2. 296 C++ implementation files
  3. 14 assembler files containing x86 assembler instructions
  4. 222090 lines of C++ code

I got the number of lines of code by counting non-empty lines, and then subtracted from them those lines that were obviously comments.

Almost all files have uppercase names.

In addition, there is a file called “RedAlert.vcxproj”, so we can assume that the project can be built in newer versions of Visual Studio, but I did not check this.

Is that all?

To begin with, there are no resources in the repository, even test ones. Therefore, you have to somehow get them legally, for example, buy a game from EA. Until you do this, even compiling the code cannot confirm the correct operation of the game.

The code is full CDMY1CDMY, there are at least 430 occurrences of this line. The repository contains the CDMY2CDMY folder, which contains implementations for the Microsoft Windows platform. No more platforms are implemented. The compiler directives for CDMY3CDMY do not have CDMY4CDMY, which I have seen for other platforms. I don’t quite understand what is the point of this, but the game supported DOS. Therefore, perhaps all the checks allow you to assemble the game so that it works under DOS, but not under Windows.

I thought I found two files, CDMY5CDMY and CDMY6CDMY, which indirectly mention the Playstation platform:

//From LCW.CPP * Project Name : WESTWOOD LIBRARY (PSX) * 

This file implements the LCW compression algorithm .

But in fact, the abbreviation “PSX” refers to the POSIX standard. There is even another implementation of the same compression function CDMY7CDMY from CDMY8CDMY, located in CDMY9CDMY. I think the implementation in C++ was used on some platforms where assembler code would not work.

Therefore, it seems to me that the company has not published the port code on the Playstation. I don’t even know if the port was created on the Playstation of Westwood itself, or was transferred to contractors.

Interestingly, the LZO and LZW compression algorithms are also implemented. Probably the strategy of Westwood Studios in choosing technologies was this: “we take everything”. The LCW algorithm would be enough to avoid Unisys patent claims on LZW, but perhaps the LZW code just remained in the source. The LZW code is used only in CDMY10CDMY, which defines the class CDMY11CDMY. The only use case for this code is commented out.


It seems that in this case, the developers tried different algorithms, as a result of focusing on LZO. That is, LZW was ready for work, but was not used.

Unisys patent claims for LZW have long expired, so we can not worry about that.

Strange headers

There are similar weird headers in LZW.H and other files:

//From the top of LZW.H/* $Header:/CounterStrike/LZW.H 1 3/03/97 10:25a Joe_bostic $ */ 

CounterStrike refers to the addition of Command And Conquer: Counterstrike.The code has 215 occurrences of the CDMY12CDMY line, changing its operation to complement it. A full explanation of the changes was written by awj on September 28, 1998 in a comment:

//From DEFINES.H #define FIXIT_CSII//Adds Aftermath CounterStrike II units//ajw 9/28/98 - Note about FIXIT_CSII. Changes seem to have been made for Aftermath ("Counterstrike II") that: a) were//bug fixes that should never be rolled back, b) change the nature of the game, at least in multi-player. This meant//that the "Red Alert" executable ( == Counterstrike executable ) could no longer be built. Apparently, at the time,//this was justified, as it was believed that no further patches to the RA executable would ever be necessary.//Given that Denzil's DVD changes and my WOLAPI integration are essentially a patch, we've got a problem.//We've decided to level the field and make sure every who gets or patches to the new version of Red Alert, CS, AM, (and//their DVD equivalent(s)) will have the same executable. So we're assuming that all of the FIXIT_CSII changes are//permanent (as, in fact, all prior FIXIT_'s are - makes me wonder why the old non-compiling code has to hang around//forever), and fixing the code so that the assumption "this is an Aftermath game" is no longer hard-coded, but can//change at runtime. (Which is what should have been done when Aftermath was created.)//<This goes for the following three defines as well.> #define FIXIT_CARRIER//Adds Aftermath aircraft carrier #define FIXIT_PHASETRANSPORT//Adds Aftermath cloaking APC//ajw - Discovered that engineer changing fields were specifically left out of aftrmath.ini, thus this has no effect.//Engineer changes (and other game rule changes) are in mplayer.ini, which was loaded before aftermath-only mplayer games. #define FIXIT_ENGINEER//Adds Engineer rules.ini overrides 

Missing source code

Questions are caused by the CDMY13CDMY library, the name of which seems to be decrypted as "Westwood Online API." It was used to search for players for online battles. It seems to the author Command & amp; Conquer: Red Alert didn’t like this library so much that he wrote a whole wrapper for it located in CDMY14CDMY. You can probably find the original CDMY15CDMY file and extract the DLL from it. But, most likely, it will not be particularly useful.

It's funny that CDMY16CDMY seems to be 9 years ago was reverse engineered .

This is not a full source release , but it should be enough to understand the game’s internal mechanics. EA said it published code to simplify the life of modders, and seems to have done it. With considerable effort, you can put together an independent game.

How does the game start?

I decided to start by exploring the process of launching the game. The startup code usually gives a good idea of ​​how the game engine interacts with the OS. The description is presented in approximately the same order as in the code itself, but not completely. All uninteresting parts are skipped.

C++ main function

The function CDMY17CDMY is declared in CDMY18CDMY. It looks like the game has recently been rebuilt as a DLL, probably for the now redesigned version. Therefore, the first thing she assigns is CDMY19CDMY.

The CDMY20CDMY function everywhere checks the CDMY21CDMY as well as the CDMY22CDMY. In CDMY23CDMY, these lines are fully commented out.

//Define DVD to turn on RADVD additions/changes - Denzil #ifdef DVD//#define INTERNET_OFF//#define MPEGMOVIE//PG//#define MCIMPEG #endif 

That is, it seems that the MPEG video playback playback functionality has been removed from the game.

First of all, the game checks to see if another copy is running; if so, then she refuses to start. This seems to be disabled using the CDMY24CDMY line. There are many parts in the code that are disabled this way, and each of them contains CDMY25CDMY. One of the committers on Git has the nickname CDMY26CDMY; I think the same person who released the project in Git was responsible for porting the game to a DLL instead of an executable file. There are many other similar parts in the CDMY27CDMY function, in the future I will simply call them disabled.

Next is the free memory check. The first check allocates 13 megabytes of memory; if this works, the code frees this memory. There is one more disabled check which tries to allocate 13 megabytes of memory in a cycle. At each iteration of the cycle, the requested allocated memory is reduced by 1 kilobyte until it can be allocated. I think we can safely assume that modern computers that run Command & amp; Conquer, there are 13 megabytes of memory needed, so it’s logical that this check was disabled.

Next, the code checks to see if the command line contains CDMY28CDMY or CDMY29CDMY, and refuses to start if so. This opens the dialog box "Playing off of the network is not allowed" and the game closes. A brief study of a headline led me to this:

"/* $Header: F:\projects\c&c0\vcs\code\wwalloc.h_v 4.9 07 May 1996 17:14:00 JOE_BOSTIC $ */" in WWALLOC.H. 

Since the path contains “vcs”, it looks like some kind of version control system was used, which acted as a disk mounted in Microsoft Windows. The last time I used IBM Rational ClearCase, it was the same. This is probably done so that people do not start the game from a network resource and do not constantly overwrite other people's save.

The game implements its own command line parsing logic written as a code built into the CDMY30CDMY function:

//From STARTUP.CPP/* ** Get pointers to command line arguments just like if we were in DOS ** ** The command line we get is cr/zero? terminated. ** */command_scan=0; do {/* ** Scan for non-space character on command line */do { command_char=*( command_line+command_scan++ ); } while ( command_char==' ' ); if ( command_char!=0 && command_char != 13 ) { argv[argc++]=command_line+command_scan-1;/* ** Scan for space character on command line */bool in_quotes=false; do { command_char=*( command_line+command_scan++ ); if (command_char == '"') { in_quotes=!in_quotes; } } while ( (in_quotes || command_char!=' ') && command_char != 0 && command_char!=13 ); *( command_line+command_scan-1 )=0; } } while ( command_char != 0 && command_char != 13 && argc<20 ); 

I did not bother checking his work; it seems that the code scans the elements indicated on the command line in quotation marks, and then tries to interpret them as groups separated by quotation marks (CDMY31CDMY). I think the Windows command line would not process such a scheme correctly, so the processing was done in the game itself. Actually, I’m not sure if the quotes logic works in CDMY32CDMY even today.

Then the CDMY33CDMY function saves the original working folder and the disk from which the game was launched, and then switches to the folder with the executable file.Curiously, by default, she selects the CDMY34CDMY drive, which Windows typically uses to drive floppy disks. Now this code execution path is completely disabled.

Next comes the first CDMY35CDMY. This directive is undefined and the Westwood Online API code is not available. If it were defined, then the game would try to find and start CDMY36CDMY, and then would check the Windows registry key, informing about the completion of the configuration. There is a rather curious comment here:

//From STARTUP.CPP//I've been having problems getting the patch to delete "conquer.eng", which is present in the game//directory for 1.08, but which must NOT be present for this version (Aftermath mix files provide the//string overrides that the 1.08 separate conquer.eng did before Aftermath).//Delete conquer.eng if it's found. if( FindFirstFile( "conquer.eng", &wfd ) != INVALID_HANDLE_VALUE ) DeleteFile( "conquer.eng" ); 

It seems that the developers after version 1.08 of the game really did not want “conquer.eng” among the files. Therefore, every time they start the game, they try to remove it. I don’t know why it is with the Westwood Online code.

Next, we move on to checking the CDMY37CDMY directive, which is undefined. If it were defined, the game would be configured to support Total Entertainment Network .

Immediately after this check, there is a check for CDMY38CDMY, which is also not defined. If it were defined, the game would have the support of MPlayer .

In the second half of the 1990s, both of them were quite popular platforms for online games. I think that there is a special assembly to support MPlayer and TEN. Neither one nor the other already exists. I’ll tell you more about them later.

The game then starts the Windows timer, waits (CDMY39CDMY) for 1000 milliseconds, and then checks that the system clock is running. If this is not so, then the game ends. I think that the implementation of CDMY40CDMY on some platforms was so buggy that it led to failure of the check at startup. This code is now disabled.

//From STARTUP.CPP #if (0)//PG int time_test=WindowsTimer->Get_System_Tick_Count(); Sleep (1000); if (WindowsTimer->Get_System_Tick_Count() == time_test){ MessageBox(0, TEXT_ERROR_TIMER, TEXT_SHORT_TITLE, MB_OK|MB_ICONSTOP); return(EXIT_FAILURE); } #endif 

Then the game checks the free space on the disk and if it is not enough, it exits. This code is now disabled.

Next, she proceeds to download the configuration generated from the CDMY41CDMY program from the original game kit. She doesn't do anything particularly interesting, but I noticed this:

: cpp//From STARTUP.CPP if (!Debug_Quiet) { Audio_Init(NewConfig.DigitCard, NewConfig.Port, NewConfig.IRQ, NewConfig.DMA, PLAYBACK_RATE_NORMAL,//(NewConfig.Speed) ? PLAYBACK_RATE_SLOW : PLAYBACK_RATE_NORMAL, NewConfig.BitsPerSample,//4, (Get_CPU() < 5) ? 3 : 5,//(NewConfig.Speed) ? 3 : 5, NewConfig.Reverse); SoundOn=true; } else { Audio_Init(0, -1, -1, -1, PLAYBACK_RATE_NORMAL, 8, 5, false); } 

The “DebugQuiet” configuration has been added; she seems to choose an audio output that does nothing. I think it would be rather annoying if you heard noise constantly while testing the game.

After that, the game is ready to adjust the screen resolution. This code is extremely interesting. The first step is to check the screen height of 400, which means the selected mode is 640 x 400. If it cannot be set, the game rolls back to 640 x 480. All other resolutions are used directly. What is so special about 640x400?

To perform rendering, the game needs access to graphics memory. If the screen width is 320, the game follows a special way of executing the code used to initialize the display buffers. I assume that if someone starts the game in 320x240 mode (which is also VGA), then he works on such an old hardware that the code does not even try to use hardware buffers. For all other heights of the screen, the code tries to allocate hardware buffers for the visible memory page and the hidden memory page. I suspect that double buffering of graphics is used, hence two buffers. For the visible memory page, the availability of hardware memory is required. A rather interesting logic is connected with the allocation of this memory:

//From STARTUP.CPP VisiblePage.Init( ScreenWidth, ScreenHeight, NULL, 0, (GBC_Enum)(GBC_VISIBLE | GBC_VIDEOMEM));/* ** Check that we really got a video memory page. Failure is fatal. */memset (&surface_capabilities, 0, sizeof(surface_capabilities)); VisiblePage.Get_DD_Surface()->GetCaps(&surface_capabilities); if (surface_capabilities.dwCaps & DDSCAPS_SYSTEMMEMORY) {/* ** Aaaarrgghh! */WWDebugString(TEXT_DDRAW_ERROR);WWDebugString("\n"); MessageBox(MainWindow, TEXT_DDRAW_ERROR, TEXT_SHORT_TITLE, MB_ICONEXCLAMATION|MB_OK); if (WindowsTimer) delete WindowsTimer; return (EXIT_FAILURE); } 

One can only assume that the comment is "Aaaarrgghh!" was added after a long debugging performance problems on individual machines. At some point, someone realized that the DirectDraw API (part of DirectX) could return a system memory page even when a hardware video memory page is requested.

Working with a hidden page is more relaxed, but its logic and comments are even better:

//From STARTUP.CPP/* ** If we have enough left then put the hidpage in video memory unless... ** ** If there is no blitter then we will get better performance with a system ** memory hidpage ** ** Use a system memory page if the user has specified it via the ccsetup program. */unsigned video_memory=Get_Free_Video_Memory(); unsigned video_capabilities=Get_Video_Hardware_Capabilities(); if (video_memory < (unsigned int)(ScreenWidth*ScreenHeight) || (! (video_capabilities & VIDEO_BLITTER)) || (video_capabilities & VIDEO_NO_HARDWARE_ASSIST) || !VideoBackBufferAllowed) { HiddenPage.Init (ScreenWidth, ScreenHeight, NULL, 0, (GBC_Enum)0); } else {//HiddenPage.Init (ScreenWidth, ScreenHeight, NULL, 0, (GBC_Enum)0); HiddenPage.Init (ScreenWidth, ScreenHeight, NULL, 0, (GBC_Enum)GBC_VIDEOMEM);/* ** Make sure we really got a video memory hid page. If we didnt then things ** will run very slowly. */memset (&surface_capabilities, 0, sizeof(surface_capabilities)); HiddenPage.Get_DD_Surface()->GetCaps(&surface_capabilities); if (surface_capabilities.dwCaps & DDSCAPS_SYSTEMMEMORY) {/* ** Oh dear, big trub. This must be an IBM Aptiva or something similarly cruddy. ** We must redo the Hidden Page as system memory. */AllSurfaces.Remove_DD_Surface(HiddenPage.Get_DD_Surface());//Remove the old surface from the AllSurfaces list HiddenPage.Get_DD_Surface()->Release(); HiddenPage.Init (ScreenWidth, ScreenHeight, NULL, 0, (GBC_Enum)0); } else { VisiblePage.Attach_DD_Surface(&HiddenPage); } } 

The same “double check” applies to this page, but the API may revert to using system memory. In the commentary, the source of such problems is called IBM Aptiva . I suspect that IBM Aptiva was the cause of many jokes during development - CDMY42CDMY even has a line CDMY43CDMY, which uses special logic to work with the IBM Aptiva computer modem.

The game then assigns ScreenHeight an exact value of 3072.The graphic buffer attached to the visible and hidden pages has a size of 3072 x 3072. As far as I understand, all the above code related to obtaining hardware memory is actually disabled using CDMY44CDMY constructs. It is so confusing that it's hard to say what is included and what is not. But all press releases about the remaster mention support for “4K”. Therefore, probably, the real resolution of the “4K” remaster is 3072 x 3072.

More recently, in 2019, comments were changed with the date and time. Someone with the JAS initials added a check to see if they start from the editor (probably the level editor) so that in this case the mouse is not intercepted. A remaster was announced in November 2018, so it is logical that during this time interval various changes should have been implemented and 4K support tested with new resource files.

The code contains all kinds of disabled logic about forcing the intro video to be played on first launch. It seems that the developer had a bipolar and he could not decide whether the user actually should see this video. At some point, all this logic was commented out; most likely during the development of the remaster. I think developers and testers quickly got tired of watching the introductory video, so I suspect that they also turned it off during the development of the original.

Now you can start playing! Next, the code executes CDMY45CDMY (from CDMY46CDMY), which is the game loop itself. In the commentary on this file, the start date is April 3, 1991, that is, for the release of the first Command & amp; Conquer took four years of development in 1995!

Upon completion of the game, CDMY47CDMY may return. It has a cleanup code, but before we get started, take a look at this:

//From STARTUP.CPP if (RunningAsDLL) {//PG return (EXIT_SUCCESS); } 

So, presumably, the graphics after the DLL remains in a strange state, which most likely leads to all kinds of memory leaks.

Other discoveries

I decided to study in more detail other aspects that interested me in file names.

Windows 95 stack traces

CDMY48CDMY file contains comment:

/* Implementation of Win95 tracing facility to mimic that of NT". */ 

It seems that it indicates that the development was carried out on Windows NT, but testing was conducted on Windows 95 to ensure the game works with the target audience. This seems logical, because NT could be available to game developers back in July 1993. I suspect that Windows 95 stack traces are horribly useless compared to what Windows NT provides.

Watcom Compiler

There is also CDMY49CDMY, which defines a lot of "#pragma" directives specific to the then very popular Watcom compiler.

This is quite interesting, because the first release of Watcom compiler with C++ support was released in 1993. There are other developer notes telling us that the project was started back in 1991. Did it start as a C project and then switch to C++? Or did the developers have another C++ compiler?

There is another treasure in the same file - it seems that some compiler developers at that time could not trouble themselves with the implementation of true and false:

//From WATCOM.H//Fix deficiency in Watcom so that true/false will be defined. #ifndef __BORLANDC__ #ifndef TRUE_FALSE_DEFINED #define TRUE_FALSE_DEFINED enum {false=0,true=1}; typedef int bool; #endif #endif 


BLOWFISH.CPP implements Blowfish encryption, which is most likely the well-known Blowfish cipher . I can only imagine one way to use it - obfuscating network traffic.

Entity System

The CDMY50CDMY class in the CCPTR.H file is a pointer type that uses CDMY51CDMY as the memory heap offset. This is a fairly standard approach because it simplifies saving files to disk if all objects are tracked from one place. It is used as a very simple way to implement an entity system. If you're curious about the benefits of using the entity system in video games, you can read more about this here .


The CDMY52CDMY class defines a template class approximately resembling std :: vector.Presumably, it was developed early on to take advantage of the STL features.


Diftong is a combination of two adjacent vowels in one syllable. How does this relate to the video game code? Honestly - no way. The strangest file is called CDMY53CDMY. Its description is in the title:

//From WIN32LIB/DIPTHONG.CPP * DIGRAM or DIATOMIC encoding is the correct term for this method. * * This is a fixed dictionary digram encoding optimized for English text. * 

In essence, this is a simple compression algorithm, assuming we are compressing texts, and performing a sequence replacement.

The code contains the magic number CDMY54CDMY, used to create several define:


The following code runs as part of the decompression of compressed data:

//From WIN32LIB/DIPTHONG.CPP if (string >= 4567) return (InternetTxt[string-4567]); ptr=(unsigned short int const *)data; return (((char*)data) + ptr[string]); 

The InternetTxt array is just a collection of predefined strings. It seems that anything equal to or greater than “4567” is considered a predefined string. I think the developer chose this constant simply by pressing the keys 4-5-6-7 lines with numbers on the keyboard. When I need to generate a random integer value as a constant, I prefer this method .

Total Entertainment Network and MPlayer

As I said above, it seems that there were special builds to support Total Entertainment Network and MPlayer. These are the services for multiplayer online games of that time.

Each service had its own initialization and configuration code.

Total Entertainment Network (TEN) Files


The following functions are used that have no implementation in the source code:

  1. tenArSendToPlayer
  2. tenArExitArena
  3. tenArIdleArena
  4. tenArReturnGameOptions
  5. tenArReturnPlayerOptions
  6. tenArSendToOtherPlayers
  7. tenArSendToPlayer
  8. tenArSetAlertMessageRoutine
  9. tenArSetIncomingPacketRoutine
  10. tenArSetOption
  11. tenArSetPlayerEnteredRoutine
  12. tenArSetPlayerState
  13. tenArSetPregameHookRoutine
  14. tenArUnreliableSendToOtherPlayers
  15. tenArUnreliableSendToPlayer

MPlayer Files (MPATH)


The following functions are used that have no implementation in the source code:

  1. MGenMoveTo
  2. MGenGetMasterNode
  3. MGenFlushNodes
  4. MGenMCount
  5. MGenSanityCheck
  6. MGenGetNode
  7. MGenGetQueueCtr

I could not find any details about the missing functions in the TEN code.

The MPATH code calls many MGen functions that are also missing. However, we can easily find them in the Quake source . Quake could also be played on both of these networks. Unfortunately, there is no TEN code in the public sources of Quake. I suppose that MPlayer integration was implemented by transferring a standard library to the studio-developer and integrating it into the game code.

I think EA was tidy because it understood that it did not own this code, and id Software at the time of the release of Quake simply did not care.

Of course, nobody really needs this code . It’s just the only thing left of the standard game services for the late 1990s.

Update: I was contacted by Larry Hastings and made corrections to some of my guesses. It turns out that the source code, which, in my opinion, was an implementation of MPlayer, is not. This is actually software called “chunnel”; it allows an application running on Windows 95 in DOS mode to interact with the network stack provided by Windows. He also shared some details about integrating MPlayer with games. I reproduce them here without mentioning the names of third parties:

First, most companies did not have their own integration with Mplayer; they just sent us a piece of code, and we had to figure out how to assemble it and do all the integration work. But I think Westwood was the exception to the rule. I remember that one of our “porting engineers” traveled before releasing Red Alert in Westwood.He was very impressed with the network model RA!

Secondly, all the assets of Mplayer were sold to GameSpy, which did not need any online services (Mplayer/POP.X/Global Rankings). All she needed was a user base and... sales, maybe? Be that as it may, in 2013 GameSpy closed, and all its assets were sold to Glu Mobile, therefore, theoretically, this company now owns all the intellectual property. TEN made a turn in the direction of “classic” online games in 1998, rebranded it in 1999, becoming, and in 2001 acquired it... EA! Therefore, EA, most likely, could safely release the TEN code. And I doubt that now anyone cares about the Mplayer code, this service has long been dead.

Thirdly, as I said, companies usually sent us a code and Mplayer itself was engaged in integration work. In the case of id Software it was the same. The Mplayer code in Quake 1 is not integration with the Mplayer game service! This is actually the technology that we licensed to id. She is called "chunnel"; it was written by a British programmer named ***. “Chunnel” is a library that allowed DOS-programs in protected mode 386 to run under Windows, making calls to the Winsock network stack of the Windows 95 operating system. It must be remembered that this was around 1996, and the video game ecosystem under Windows has not yet developed. Quake was originally released as a DOS program, and it was ported to Win32 only after one or two years. “Chunnel” allowed id to solve a serious problem - it provided its DOS-program in protected mode 386 with the opportunity to participate in a network game while working under Windows. Partially, the company was grateful that each id game used Mplayer (despite the fact that it was always in doubt). When launching the first versions of Quake under DOS, for example, the first shareware demo, the Mplayer logo (a golden waveform) and a note about “licensed technology” were even present on the splash screen. This also explains the -mpath command-line option in Quake DOS assemblies ;-)

Translation and localization

Games are usually ported to other languages ​​so that they can be sold not only in English-speaking markets. Interestingly, localization was at least partially implemented using the CDMY55CDMY constructions scattered throughout the code, as well as testing the CDMY56CDMY before defining aspects such as CDMY57CDMY.

Verification CDMY58CDMY occurs 28 times in code, but CDMY59CDMY occurs 37 times. Maybe translating into French was just a little more thorough.

Of course, CDMY60CDMY presents the best translation implementation ever.

//From DEFINES.H//#define SPAIN 1 (never used) 

It seems that the developers didn’t get to the Spanish translation.

Dongle Defense

For a certain period of time in the past, the standard way of DRM protection of various software was dongle hardware key . Essentially, a closed and obfuscated hardware device connected to a PC was used for protection. The program sends him a certain “request” and refuses to start if it does not receive the desired answer.

I don't think Command & amp; Conquer was once sold with such a device, but CDMY61CDMY has one or two commented lines about it:

//From DEFINES.H/********************************************************************** ** ColinM ** Set this to enable dongle protection *///#define DONGLE 

Virgin Interactive

Command & amp; Conquer was developed by Westwood Studios, but Virgin Interactive owned the company. The code has such a check with a unique name:

//From DEFINES.H/********************************************************************** ** If this is defined, the special Virgin limited cheat keys ** are enabled. This allows the "cheat" parameter and then only ** allows the ALT-W to win the mission. */#ifdef PLAYTEST_VERSION #define VIRGIN_CHEAT_KEYS #endif 

//From INIT.CPP #ifdef VIRGIN_CHEAT_KEYS case PARM_PLAYTEST: Debug_Playtest=true; break; #endif 

I think that Virgin Interactive received a special assembly before the release to playtest the product.

The End

That's all. I did not examine the entire code, I just looked at what seemed interesting to me and what was enough time. I learned a little more about the development of video games in the early 1990s, and maybe I can use this knowledge in the present.

Perhaps in the future I will return to the study of this code. I would really like to compare it with the port of the game on the Playstation, but I do not think that EA will be able to release this code, even if it still has it.