This means that you must already own a legal copy of that system. In most cases, emulators do not include the operating system being emulated they only provide an environment in which that system can run. On the other hand, if both operating systems expect to find the same physical hardware in the machine, there will be no reason to emulate the hardware. Instead, a "runtime environment" is used to negotiate between the two systems. If both BeOS and the alien OS are compatible with the physical hardware, emulation is not required. If the alien OS requires different hardware than that which is physically present in the machine, a true emulator is required to create the illusion of that hardware in system memory. In fact, it's theoretically impossible for a system to run in emulation as quickly as it does on its native hardware (however, older operating systems are often emulated on current hardware, making it possible to more than compensate for performance penalties). Understandably, this process consumes a lot of resources, which usually makes true emulation cumbersome and slow. If you want access to your disk drives, and want your monitor and keyboard to work, the emulator has to communicate hardware calls back to the host OS, which in turn sends them to the physical hardware. But it's not enough to just emulate a physical hardware environment in software. What's the distinction? As seen in Figure 1, when the alien OS cannot use the machine's physical hardware, an emulator must fool it into thinking that the hardware it wants is actually present.
Softc on sheepshaver software#
There is no intended implication that some of these operating systems seem to have been designed by aliens.īefore we dig in, it's important to distinguish between true emulation, where the emulating software actually mimics another platform's hardware, and "runtime environments," where the original hardware is not emulated and a sort of "negotiating layer" is used instead. The term "alien system" refers to the OS being emulated, since it's being run outside of its natural home. In this chapter, the term "host system" refers to the primary running operating system-the OS that booted the machine and that has ultimate control over the physical hardware. Some of the emulators covered here (like SheepShaver, the MacOS emulator, which isn't truly an emulator at all) can be genuinely useful, while others (like BeBeeb, the Acorn Micro emulator) are probably around only for nostalgia's sake. This chapter offers only a brief overview of the emulators available for BeOS as of R4.0. While some people experiment with emulators out of curiosity rather than necessity, a well-implemented emulator can save you from having to reboot by enabling you to accomplish tasks that normally can only be done in another system. When you're playing a full-screen game, for example, the game emulates another world within the context of BeOS.īut why stop with spaceports and mystical worlds? Why not emulate entire operating systems running on other types of hardware? BeOS emulators exist to let you run a copy of the AmigaOS or the MacOS inside a BeOS window, play Nintendo cartridge games in system RAM, or pretend that you're sitting at the helm of an ancient Sinclair Spectrum. But the environment suggested by the operating system is never absolute-just because most of your apps conform to the general appearances and behaviors of the BeOS universe, that doesn't mean that all of them have to. Whether you're deep in the dungeons of Doom or typing away in a BeatWare Writer document, your hardware fades into invisibility as the interface takes over. When you use a computer, you don't think about the hardware you're running-you're immersed in a visual environment governed by the operating system and its applications.
0 kommentar(er)
