Windows 95 does not support asynchronous file input and output (I/O), except on serial devices. Therefore, the ReadFile and WriteFile functions will fail if you pass in an overlapped region on anything other than a serial device. The GetOverlappedResult function works only on serial devices or on files opened by using the DeviceIoControl function.
In Windows 95, the ReadFileEx and WriteFileEx functions will fail if you pass in the handle of a serial device (for example, COM2). ReadFile and WriteFile, however, accept the handle of a serial device.
In Windows 95, the CreateFile function does not support the standard "\\.\C:" and "\\.\PhysicalDrive0" formats used to gain access to the logical or physical drives. To gain access, applications must specify a virtual device (VxD) name instead and use the DeviceIoControl function to send requests through the VxD to the logical and physical drives. For more information, see Device I/O Control.
In Windows NT, the DeleteFile function fails if you attempt to delete a file that is open for normal I/O or is opened as a memory mapped file. In Windows 95, DeleteFile deletes such files. Because deleting open files may cause loss of data and application failure, you must take every precaution to close files before attempting to delete them by using DeleteFile.
In Windows NT, the FileTimeToDosDateTime and DosDateTimeToFileTime functions allow dates up to 12/31/2107. In Windows 95, these functions allow dates up to 12/31/2099.
The precision of the time for a file on a file allocation table (FAT) file system volume is 2 seconds. If Windows 95 is connected through a network to a different file system, the time precision is limited only by the remote device.
In Windows 95, fixed memory blocks cannot be reallocated to be movable. The GMEM_MODIFY and GMEM_MOVEABLE combination of values has no effect when a memory block is reallocated by using the GlobalReAlloc function. Similarly, the LMEM_MODIFY and LMEM_MOVEABLE combination has no effect when a memory block is reallocated by using the LocalReAlloc function.
In Windows 95, committing memory for a page that is already committed is an expensive operation that has no ultimate effect (it is expensive because additional storage is allocated and subsequently freed for each committed page). When committing memory by using the VirtualAlloc function, an application should specify only the pages that actually need to be committed.
Although applications can request that memory allocation be at a specific virtual address, applications must not depend on any given address range always being available on every operating system. Applications can query the address space by using the GetSystemInfo function.
In Windows 95, memory allocated by Win32-based applications falls in the address range 4 megabytes (MB) – 2GB for private memory and 2GB – 3GB for shared memory (shared mapped files). The PAGE_WRITECOPY and PAGE_GUARD access protection values are not supported. Instead of using the PAGE_GUARD value and handling the EXCEPTION_GUARD_PAGE exception, applications can use the PAGE_NOACCESS value and handle the EXCEPTION_ACCESS_VIOLATION exception.
The SEC_IMAGE and SEC_NOCACHE values for the fdwProtect parameter of the CreateFileMapping function are not supported in Windows 95. In addition, the dwMaximumSizeHigh parameter of CreateFileMapping is ignored in Windows 95, so applications should specify zero for the parameter.
In Windows 95, shared memory mapped files that are created by using the MapViewOfFileEx function appear in the same address space across all 32-bit processes in the system. If you pass in a specific base offset in the lpvBase parameter of MapViewOfFileEx and the function succeeds, you are guaranteed that the same memory region is available in every process. This is not true in Windows NT because MapViewOfFileEx fails for any process that already has the given memory region in use.
Coherence guarantees that the data accessible in a file view is an identical copy of the file's contents on disk. In Windows 95, file views derived from a single file-mapping object are coherent only if the file is accessed through one of the views. A view of a file is not guaranteed to be coherent if the file is accessed by normal file I/O functions, such as ReadFile or WriteFile, or by views created from a different file-mapping object.
If you close a file handle that was used to create a file mapping object, both Windows NT and Windows 95 hold the file open until you unmap the last view of the file by using the UnmapViewOfFile function. However, Windows NT holds the file open with no sharing restrictions, whereas Windows 95 holds it open using the sharing restrictions of the original file handle. To ensure exclusive access to a file in Windows NT, the file handle must remain open for the life of the file-mapping object. Because Windows 95 retains the sharing restrictions, both the file handle and the handle to the file-mapping object may be closed after calling MapViewOfFile and exclusive access to the file is ensured.
In Windows 95, if the FILE_MAP_COPY value is specified for the fdwAccess parameter of MapViewOfFile (or MapViewOfFileEx), the hMapObject parameter must have been created with the PAGE_WRITECOPY value. In addition, the dwOffsetHigh parameter of MapViewOfFile (or MapViewOfFileEx) is ignored, so applications should specify zero for the parameter.
Windows 95 implements copy-on-write file mappings slightly differently than Windows NT. In Windows 95, a call to MapViewOfFile with FILE_MAP_COPY returns an error unless PAGE_WRITECOPY was used with the CreateFileMapping function. In both Windows NT and Windows 95, creating the map with PAGE_WRITECOPY and the view with FILE_MAP_COPY produces a view to the file that makes the pages swappable and prevents modifications from going to the original data file. In Windows 95, PAGE_WRITECOPY must be passed to CreateFileMapping, but this is optional in Windows NT.
If you share the mapping between multiple processes by using the DuplicateHandle or OpenFileMapping function and one process writes to a view, the modifications will not be propagated to the other process in Windows NT. However, the modifications will be propagated in Windows 95. The original file, though, will not change on either platform.
The Windows 95 registry does not allow key names containing control characters. In addition, if the lpszSubKey parameter is an empty string (""), the RegDeleteKey function deletes the key identified by the hKey parameter.
In Windows 95, the RegCreateKeyEx function creates a non-volatile key even if the REG_OPTION_VOLATILE value is specified.
In Windows 95, the DuplicateHandle function cannot duplicate handles of registry keys as it can in Windows NT. The function returns an error if an application attempts to duplicate the handle of a registry key. In addition, when a file handle is duplicated, the duplicated handle will not be granted more access than the original.
Thread locales, retrieved and set by using the GetThreadLocale and SetThreadLocale functions, are static and can only be changed at system boot time.
In Windows 95, the FlushInstructionCache function always returns TRUE. Windows 95 supports single processor machines only.
In Windows 95, a call to the FreeResource function must be included for every call to the LoadResource function. The call to FreeResource allows the system to discard a resource that an application no longer needs. Windows NT automatically frees resources, so a call to FreeResource is not required.
The SYNCHRONIZE standard access rights flag is not supported in Windows 95. The following functions are affected.
| DuplicateHandle | OpenSemaphore |
| MsgWaitForMultipleObjects | WaitForMultipleObjects |
| OpenEvent | WaitForMultipleObjectsEx |
| OpenMutex | WaitForSingleObject |
| OpenProcess | WaitForSingleObjectEx |