cff said:
Well in Assembly I should at least have comments and meaningful variables.
But that wasn't the point. You claimed that code done in a higher language would be so much easier to port. Which I said isn't true.
Well, for one, I never said that code done in a higher language would be so much easier to port, especially since you evidently include higher languages that people are developing concurrently with the program being programmed in that language (anybody else see a problem with that scenario?). I did list a number of reasons why assembly language is a waste of time for modern programs, and should only be used selectively to optimize the most performance-critical parts, or parts that use special instructions (like SSE or MMX) which can't be automatically generated by current compilers; and even then, ideally you should still have a portable path that doesn't rely on special instructions.
"Rewriting the program" does not equal a portable program, which is essentially what you're advocating with assembly language. Even the syntax of assembly language programs varies from platform to platform, and assembler to assembler. Furthermore, when you write in assembly language, you're forced to reimplement all the interfaces to the hardware or operating system which you get for free with the various libraries built in to higher level languages. That's even ignoring all the opportunities for code reuse of utility routines for doing things like 3D graphics or sound. (How many times do people write software renderers from the ground up these days? When's the last time anyone wrote a hardware-accelerated render that didn't use a standard API?)
My preferred programming language for portable programs is C, which has been successfully used even to program operating systems portably. A well-written C program can essentially be recompiled with few or no changes on any platform with a standard C compiler, which is just about any serious computing platform out there, dating back to the 1970s. Most
programming languages are initially written in C because of this. Once you can bootstrap from the C compiler, you can then port higher level programming languages of your choice, like Java, Perl, or Python. Usually, you don't even need to do this yourself, because somebody else has already done the work for you. With assembler, the only way you're going to automatically port that program is to have somebody write a program which can automatically translate the assembler of one architecture into another. Now, how many programs have you seen that do that? It's not a trivial task.
The use of higher-level programming languages is why you can find games today that run on PCs, Macs, Xbox, PlayStation, and GameCubes, often released practically simultaneously. Reusable libraries let people license the most performance-critical code from third parties (who can often optimize the performance many times better than the game developer could anyway), and focus on writing the game-specific logic to standard APIs in the portable programming language of their choice (generally C or C++, since these are easily compiled into machine language and have little overhead, but I suppose you could use others).
High level languages also allow you to use them as scripting languages, which can greatly accelerate the amount of code you can write. Many studies have shown that the number of lines of code that a programmer can produce is more or less fixed, regardless of the programming language. So yes, you can probably write as many lines of assembly as Java per hour, but a single line of Java can be equivalent to hundreds of lines of assembly. The MMORPG EVE uses stackless Python to implement most of its behavior as scripts, an approach which is quite popular these days. Scripting languages and standard C-compatible build tools have allowed the emergence of modding as a major activity, rather than the lunatic fringe of a few hardcore hackers.
Compare the relative success of Secret Ops modding efforts to those of, say, Half-Life or even Homeworld 2--it's taken years to work out how to significantly hack into Secret Ops, an engine which wasn't designed for modding by the community, while you've had mods like Counter-Strike initially released by a 1-man team in a relative short time period, which practically completely rework Half-Life into a completely different game, thanks to the availability of the HL SDK. Even before the major success of Counter-Strike, you had significant modding going on with the id engines that Half-Life was based on, especially starting with the first Quake, which id designed to be more moddable after all the fan activity surrounding the Doom engine (which was mainly restricted to replacing images, sounds, and other media assets, until the release of the Doom source code). The main way they enabled this trend was the development of QuakeC, a high level scripting language.
It's highly unlikely that any of this would have been possible if people had been forced to write to a custom binary interface that specified how registers were supposed to be manipulated in great detail, and it's highly unlikely that GLQuake (which runs under Windows, not DOS) could have been developed so easily and spawned the 3D accelerator revolution if the code couldn't have been easily recompiled and reworked to use the OpenGL API and run under Windows, nor (although I suppose this isn't too important to Wintel gamers) would games using Quake-derived (and Unreal-derived) engines be running on Linux or the Macintosh at all.
cff said:
GeeBot said:
I brought up Privateer because it uses an assembly hack (VMI, I think) to perform memory management. This hack doesn't work under Windows XP, for various reasons, some of which include the hack making multitasking virtually impossible.
And that is where you are completely wrong. There had been two memory models for DOS. EMS and VCPI. Both provided by EMM386. Neither is better, faster more standard or anything. 95% of programmers seem to have prefered EMS. So Microsoft completely ignored to include VCPI into Windows. Privateer needs VCPI. There is no hack. There is no ignorance. This has nothing to do with assembler. It is simply a screwup my MICROSOFT! And do, multitasking doesn't have anything to do with it either.
I want to keep this civil, but you're beginning to try my patience with these unresearched opinions. I was thinking of trying to get Privateer to run natively under XP at one point, so I thoroughly investigated the reasons why Privateer couldn't run under a Windows DOS box, either in Windows 98 or Windows XP (I eventually decided the project wasn't worth the time, considering emulators could run Privateer at a decent speed on today's machines). The problem was the use of VCPI. The problems with VCPI were fixed in the development of DPMI, which is compatible with being hosted in a virtual DOS box. The development of VCPI and DPMI weren't strictly for memory management, but originally as an interface into protected mode functions which normally can't be accessed in DOS's real mode, so EMS and XMS can't be simply substituted (that's what lead to the development of DOS protected mode managers for games; remember DOS4GW, which usually printed a little blurb before the startup of many games, mainly written using Watcom tools?). Some of the uses of VCPI and DPMI were for task switching environments like DESQview and TSRs, which needed to access special protected mode functions to function properly while running in the "background".
VCPI requires switching all control to a VCPI server, which has to run in protected mode. Multitasking operating systems must run in protected mode, and they can't be switched out, since that would allow a VCPI program to seize complete control away from the operating system. At the minimum, emulation compatible with modern multitasking operating systems would require instruction-level emulation of at least protected mode. This isn't impossible, but it's not an option Microsoft has chosen to pursue. It's also slow and a massive undertaking to do from scratch (note the complexity and speed of such solutions as VirtualPC, VMware, Bochs, etc.). There are some rumors that Microsoft will be bundling an emulator into the next release of Windows.
In order to run Privateer in a virtual DOS box without instruction-level emulation requires that somebody write an emulator for the protected mode VCPI server. This can be done by telling Windows that a third party driver will handle the VCPI interrupt, rather than the default response of reporting the program can't be run in a DOS box. The third party driver can then do whatever is necessary to emulate the Privateer's VCPI component. However, this solution is specific to a single program; you need to do a rewrite for every single program you want to run that uses VCPI. Obviously, this would be impractical to do, even for Microsoft. I believe this actually has been done with the Privateer Windows 98 compatibility hack that was recently released, but there's no such solution currently in existence for the NT-derived versions of Windows (although there's no theoretical reason why it couldn't be done, using the NT VDM hooks perhaps).
