Windows 3.1x
Fundamentally, Windows 3.1x has a 16-bit design. Its kernel, most major system components, and native applications are largely implemented in 16-bit code. (Its little-used Win32s API supports 32-bit apps, but it doesn't support threading.)
All native Windows 3.1x applications and all of Windows' own system DLLs are mapped into a common segmented virtual address space, 4GB in size. All these components are visible to (and often writable by) each other. At the bottom of this address space, usually below the 1MB mark, are the real-mode device drivers that provide an interface to peripheral subsystems such as video cards or printers. Windows 3.11 does use VxDs for the file system, providing a protected-mode path to disk.
This stripped-down design provides a very small working set, (the application and system code that must be loaded for any given task), so Windows 3.1x can run well on systems with limited RAM. It also allows for very efficient code execution, since programs can call API functions from within their own memory space. Its drawback is a lack of protection when something goes wrong. Since programs and system components are visible to each other, a buggy program can easily overwrite memory belonging to another process. While Windows 3.1x is capable of recovering from some of these general protection faults (GPFs), the outcome is often a system-wide crash.
Windows 3.1x runs multiple applications through a simple scheduling mechanism called cooperative multitasking. Under this system, each application is responsible for voluntarily giving up control when it checks its message queue and finds it empty. But if an application fails to check its message queue, either because it is busy or because it hangs, other applications are kept from their share of OS resources.
Another frustration Windows 3.1x users have long faced is the limited size of GDI and USER resources. These constraints are due to the fact that the GDI and USER system DLLs use several 64K heaps for storing a variety of arcane data structures created by running applications. When these small heaps fill up, you see an out-of-memory error even with plenty of free memory left.
WINDOWS 95
Windows 95 represents an evolutionary development of Windows 3.1x rather than a clean break with the past. While it brings many significant changes to the 16-bit Windows architecture, it also keeps some of its essential features. The result is a hybrid OS, one that can run 16-bit Windows and DOS legacy apps and older real-mode device drivers while supporting true 32-bit applications and 32-bit VxDs.
The most important improvements Windows 95 brings include native support for 32-bit multithreaded applications, protected address spaces, preemptive multitasking, far more extensive and efficient use of VxDs, and increased use of 32-bit heaps for storing system-resource data structures. Its most significant drawback is that it is still relatively unprotected from badly behaved applications.
Each native Windows 95 application sees a flat 4GB address space containing itself plus the Windows 95 system code and drivers. As far as each 32-bit application is concerned, it is the only application on the PC. The application code loads into this address space from the 4MB to the 2GB mark. Although 32-bit apps can't see each other, they can pass data to each other via the Clipboard, DDE, and OLE. All 32-bit applications are preemptively multitasked on a per-thread basis. The thread scheduler, a part of the virtual memory management (VMM) system, distributes system time among the pool of current threads based on each thread's priority level and readiness to run. Preemptive scheduling offers far smoother and more robust multitasking than the cooperative method used in Windows 3.1x.
The Windows 95 system code resides above the 2GB mark. In the range of 2GB to 3GB are the Ring 3 system DLLs and any DLLs that are used by multiple programs. (Intel 32-bit processors offer four hardware-enforced protection levels named Ring 0 through Ring 3. Ring 0 is the most privileged.) Windows 95's Ring 0 components are mapped from 3GB to 4GB. These important, highly privileged pieces of code include the VMM subsystem, the file system, and VxDs.
The area of memory from 2GB to 4GB is mapped into the memory space of every 32-bit application so it is shared by all 32-bit apps on your PC. This design allows API calls to be serviced directly within the application's address space, and it limits the size of the working set. The downside is compromised robustness. There is nothing to stop a buggy application from scribbling on addresses belonging to system DLLs, crashing the entire show.
The area from 2GB to 3GB also contains any 16-bit Windows applications you may be running. For compatibility reasons, these execute in a shared address space, where they can corrupt each other just as they can in Windows 3.1x.
The memory addresses below 4MB are also mapped into the address space of each application and are shared by all processes. This makes compatibility with existing real-mode device drivers possible, since they require access to those addresses. It also opens up another area of the memory map to malicious scribbling. The very bottom 64K of this address space is not addressable by 32-bit applications, in order to catch faulty pointers, but it is addressable by potentially buggy 16-bit applications.
Some Windows 95 system DLLs, USER and GDI in particular, still contain 16-bit code. One unfortunate result of this is that USER's and GDI's 64K local heaps and their attendant system-resource limitations are still with us. Fortunately, Windows 95 did move a number of data structures into 32-bit heaps, making it far harder to run out of system resources than under Windows 3.1x. Another problem raised by 16-bit system code is the Win16Mutex effect. Since 16-bit system code is nonreentrant, only one thread can access 16-bit DLL functions at a time, potentially hobbling other processes that need access to the DLL in question.
Intel Hardware Processing Modes:
Operating System Multiprocessing Modes:
V. Video
pixels, resolution, refresh rate, color depth
VGA, SVGA
MPEG (hardware)
video capture
1. Bandwidth
2. Multicasting
transmission of data from one source to many destinations
3. Real-time constraints
essential for applications that have ‘live’ sources or must present synchronized audio and video streams.
Specifies the minimum % of acceptable data loss.
Allows applications with different communication requirements to specify their own set of minimum parameters.
e.g. An audio stream might request the following QoS parameters:
bandwidth: 64 kbps
maximum delay: 100 ms
maximum loss rate: 1%
The network would then allocate sufficient resources to satisfy the application’s demands, or tell the application that the network is ‘busy’.
MPC Specification
The Development Process
Use the Multimedia 101 section of the Macromedia Showcase Disk. Go through the following sections:
Powerpoint Lecture and Demonstration
Go through the tutorial.
Refer the students to the CIS 5.2 textbook.
Assign homework:
Choose a thesis and create a 10 slide presentation proving your point. Submit a printout and a disk containing the self running presentation.
Game Development
Text Þ Cartoon like Þ video Þ Virtual reality
examples:
adventure
pong
Leisure Suit Larry
Mist (go through the development process)
Star Trek Interactive Manual
