Hubbry Logo
UWINUWINMain
Open search
UWIN
Community hub
UWIN
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
UWIN
UWIN
UWIN
View on Wikipedia
from Wikipedia

UWIN is a computer software package created by David Korn which allows programs written for the operating system Unix to be built and run on Microsoft Windows with few, if any, changes. Some of the software development was subcontracted to Wipro, India. References, correct or not, to the software as U/Win and AT&T Unix for Windows can be found in some cases, especially from the early days of its existence.

UWIN source is available under the open source Eclipse Public License 1.0 at AT&T's AST/UWIN repositories on GitHub.

UWIN 5 is distributed with the FireCMD enhanced Windows shell with the Korn Shell thereof as one of three default shells present at install, the others being the FireCMD scripting language and the default Windows command shell cmd.exe. Other UWIN shells like csh and tclsh and those of other interoperability suites like the MKS Toolkit and other shells like those that come with Tcl, Lua, Python and Ruby distributions inter alia can be added to the menu by the user/administrator.[1]

Technical details

[edit]

Technically, it is an X/Open library for the Windows 32-bit application programming interface (API), called Win32. UWIN contains:

  • Libraries that emulate a Unix environment by implementing the Unix API
  • Include files and development tools such as cc(1), yacc(1), lex(1), and make(1).
  • ksh(1) (the Korn Shell) and over 250 utilities such as ls(1), sed(1), cp(1), stty(1), etc.

Most of the Unix API is implemented by the POSIX.DLL dynamically loaded (shared) library. Programs linked with POSIX.DLL run under the Win32 subsystem instead of the POSIX subsystem, so programs can freely intermix Unix and Win32 library calls. A cc(1) command is provided to compile and link programs for UWIN on Windows using traditional Unix build tools such as make(1). The cc(1) command is a front end to the underlying compiler that performs the actual compilation and linking. It can be used with the Microsoft Visual C/C++ 5.X compiler, the Visual C/C++ 6.X compiler, the Visual C/C++ 7.X compiler, the Digital Mars C/C++ compiler, the Borland C/C++ compiler, and the MinGW compiler. The GNU compiler and development tools are also available for download to UWIN.

UWIN runs best on Windows NT/2000/XP/7 with the file system NTFS, but can run in degraded mode using FAT, and further degraded on Windows 95/98/ME. (See the External link for more details.) A beta version for Windows Vista and 7 is released as UWin 5.0b (June 2011, 17th).[2] On January 19, 2016, it was announced by AT&T that the AST and UWIN source packages were migrated to GitHub.[3]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

UWIN

View on Grokipedia
from Grokipedia
UWIN (Unix for Windows) is a software package developed by David Korn at Laboratories that provides a POSIX-compliant interface layer built on top of and operating systems, allowing Unix programs to be compiled, built, and executed in a Windows environment without requiring multiple code versions or proprietary middleware. The project addresses the need for an open, cross-platform development environment by implementing X/Open Release 4 headers, system interfaces, and approximately 175 Unix commands, including the (ksh-93) and support for socket programming. Key components include dynamic link libraries such as posix.dll for functionality and ast52.dll for additional AT&T System V libraries, which map Unix system calls to the while handling challenges like process creation (via emulation using reparenting), signal management (through threads and exception filters), and pathname translation (e.g., converting /d/bin/date to d:\bin\date). A server component, UMS (Unix Management Server), manages /setgid permissions and user/group databases on , enhancing security and portability. UWIN was presented at the Windows NT Workshop, August 11–13, 1997, in , Washington, where it demonstrated superior performance over Microsoft's built-in subsystem in areas like library size and conformance, comprising around 15,000 lines of code for its core implementation. Originally freely available for non-commercial use via Research and commercially through GTL Inc., UWIN has since been released as under the 1.0 and is hosted on by , with versions advancing to at least 5.0, including features like UNC pathname support and a /sys pseudo-directory for improved portability across Windows platforms; version 5.0 is distributed with the FireCMD enhanced . Despite its achievements, ongoing challenges include file naming conventions, integration, and full multi-user support on Windows 95.

Overview

Development

UWIN was primarily developed by David Korn at AT&T Laboratories in Florham Park, New Jersey, beginning in early 1995. Korn, who had previously created the KornShell (ksh), a widely used Unix command language and shell developed in the early 1980s at Bell Labs, led the project to address the challenges of reusing AT&T's existing Unix tools and libraries on Microsoft Windows platforms. The initial motivation stemmed from the need to port these Unix applications to Windows NT and Windows 95 without requiring full rewrites or extensive conditional compilation, thereby minimizing development effort and maintaining a single codebase. Korn completed the foundational framework for UWIN—a POSIX-compatible interface layer over the Win32 —in approximately three months, drawing on X/Open Release 4 standards to ensure compatibility. The project later expanded with contributions from a small team of two to three developers at and subcontracted support from in . By mid-1997, UWIN reached a stage where version 1.2 was released in binary form for non-commercial use via AT&T Research's website. Key milestones included the public presentation of UWIN at the Windows NT Symposium in August 1997, where Korn delivered the paper "UWIN: UNIX for Windows," detailing the system's architecture and achievements. This coincided with the release of version 1.3, which introduced support for UNC (Universal Naming Convention) paths and the /sys directory, enhancing file system integration with Windows networking features. These developments marked UWIN's transition from an internal tool to an accessible software package for porting Unix applications to Windows environments.

Purpose

UWIN was developed to provide a environment on Windows platforms, specifically Windows NT and Windows 95, enabling developers to build and execute Unix applications with minimal modifications to the source code. By implementing a Unix interface layer atop the Windows operating system, UWIN allows Unix programs to compile and run natively without requiring extensive efforts, thus bridging the gap between Unix and Windows ecosystems. This approach facilitates the reuse of existing Unix tools, libraries, and scripts in a Windows context, supporting both development and runtime needs. A primary benefit of UWIN is the reduction in development costs for organizations maintaining software across multiple platforms. It permits the use of single-source codebases that can target both Unix and Windows environments, eliminating the need for dual maintenance or platform-specific adaptations. This is particularly advantageous for Unix developers seeking to extend their applications to Windows users, as it minimizes the overhead associated with rewriting code or managing separate builds. UWIN's Unix interface layer specifically supports the creation, testing, and execution of POSIX-compliant applications on Windows, providing a familiar environment for Unix-centric workflows. The includes Unix software developers requiring Windows compatibility and enterprises aiming to avoid fragmented codebases, thereby enhancing and code portability in cross-platform scenarios.

Architecture

Components

UWIN's foundational components consist primarily of two dynamically linked libraries: and ast52.dll. The implements the core functions, maintaining an open file table shared across processes in a memory-mapped and mapping Unix-style pathnames to Win32 equivalents, such as converting /d/bin/date to d:\bin\date. It also handles mapping to Windows handles using a Pfd_t structure, allowing Unix s to correspond to one or more Win32 handles, particularly for console operations. Meanwhile, ast52.dll provides a portable interface to the libast.a (version 5.2), including extensions like a custom stdio implementation via Sfio, which manages line delimiters by converting Windows-style to Unix for compatibility. The Unix Management Server (UMS) operates on as a background process running under Administrator privileges, managing aspects such as generating tokens for and setgid operations, synchronizing /etc/passwd and /etc/group files with the , and facilitating process management. This server ensures Unix-like user and group handling within the Win32 environment, though it is not supported on Windows 95. To enable Unix application development and compilation on Windows, UWIN includes a comprehensive set of header files and libraries that replicate a Unix environment, covering nearly all X/Open Release 4 interfaces and allowing tools like and make to function without source modifications. These components support POSIX.1 standards as detailed in the standards compliance section. Additional features in UWIN's components include support for runtime dynamic linking, enabling shared libraries for tools like the Korn shell (ksh-93), though with limitations such as no function overriding in Win32 DLLs. Later versions, such as 1.3, introduce Universal Naming Convention (UNC) support for paths like //hostname/filename, enhancing network file access. Throughout, UWIN integrates deeply with the Win32 API for underlying system calls, including file systems, sockets, and processes, while allowing seamless interoperability such as passing environment variables or file descriptors between Unix and native Win32 commands.

Platform differences

UWIN exhibits significant platform differences in its implementation on compared to , primarily due to the underlying architectural disparities between these operating systems. On , UWIN provides full support for the security model, including access control lists (ACLs) and setuid/setgid mechanisms, which are mapped to NT's native security descriptors via the Unix Management Server (UMS) server. This server, running with Administrator privileges, handles and manages security tokens, enabling robust user and group management that integrates with Windows domains. Additionally, streams are utilized to represent special files such as symbolic links and device files, preserving semantics like . These features allow for better and concurrency, as NT's kernel supports multiple processes sharing memory while maintaining security boundaries. In contrast, Windows 95 lacks a native security model equivalent to NT's, resulting in no support for ACLs, /setgid, or the UMS server; such operations return "not implemented" errors. File handling is constrained to FAT or HPFS file systems, which do not support , leading to simplified representations of special files—such as using Windows shortcuts for symbolic links—and the absence of execute permissions or case-sensitive path handling. features are reduced due to Win32 API limitations on 95, with no dedicated subsystem, resulting in weaker and no native user/group management beyond basic . and domain integration are unavailable, limiting UWIN's utility to lighter, non-privileged workloads. Overall, UWIN was designed primarily for as the primary target, leveraging its advanced kernel for comprehensive UNIX compatibility, while serves as a secondary platform for basic portability with acknowledged constraints in and file system capabilities. Core DLLs like libgen provide shared functionality across both, but platform-specific behaviors dictate the extent of compliance.

Features

Standards compliance

UWIN provides compliance with the IEEE 1003.1 (POSIX.1) standard, implementing the core Unix system calls necessary for portable application development, including support for sockets and (IPC) mechanisms such as , message queues, semaphores, and . This adherence ensures that applications written to the POSIX.1 interface can execute on UWIN with minimal modifications, facilitating cross-platform portability from Unix systems to Windows environments. In addition to POSIX.1, UWIN conforms to the X/Open Portability Guide Release 4 (XPG4), which extends the Unix interface with additional utilities, headers, and features for broader compatibility across Unix variants. Key elements aligned with these standards include dynamic linking for shared libraries, memory file mapping for efficient data access, and terminal emulation through the termios interface, enabling consistent handling of and control operations. UWIN offers partial support for extensions, such as and setgid privileges for process execution, but this functionality is limited to platforms using file systems, where it relies on privilege delegation mechanisms. While it includes some System V IPC facilities and BSD-derived sockets layered over the Windows Sockets , UWIN does not provide full compatibility with System V or BSD interfaces, instead prioritizing a portable subset of features to avoid platform-specific dependencies. This focused approach supports approximately 175 Unix utilities and tools, such as compiler wrappers, while maintaining standards-based interoperability.

Included tools

UWIN bundles approximately 175 Unix utilities and development tools, primarily developed by , to enable immediate usability for building and running Unix applications on Windows without extensive modifications. These tools cover essential command-line operations, scripting, and compilation, drawing from AT&T's AST (AT&T Software Technology) toolkit to approximate a Unix environment. Among the core shells provided is ksh-93, the with features like job control and dynamic linking, serving as the primary interactive and scripting interface. Development utilities include parsers and builders such as for generating parsers, lex for , make for dependency-based builds, and nmake as an enhanced version compatible with Windows environments. Text processing is supported through editors like vi, ported from BSD sources for line-oriented editing, and viewers such as less for paginated file display. Compression and file utilities encompass for LZ77-based file compression, alongside various processing tools for tasks like archiving and data manipulation. For software compilation, UWIN offers wrappers including cc for ANSI C programs and CC for C++ code, interfacing with Microsoft Visual C/C++ compilers (versions 2.x through 5.x) to facilitate cross-compilation. These wrappers ensure POSIX-compliant invocation, such as pcc for POSIX standards. Graphical application support includes X Windows client libraries, allowing Unix X11 clients to run on Windows by routing calls through UWIN's interface, though porting may require handling platform-specific directives. The build environment provides essential headers for standard libraries, enabling porting of Unix source code with minimal adjustments to achieve X/Open Release 4 conformance in utility behavior.

Limitations and challenges

Technical limitations

UWIN imposes several restrictions on file naming conventions inherited from Windows file systems, such as prohibiting filenames that end in a period (".") or reserved names like "aux," "com1," or "nul," which are invalid under the WIN32 API and can lead to unexpected behavior in Unix applications expecting flexible naming. These limitations arise because UWIN maps Unix file operations to Windows or semantics, which lack full and compliance without specific flags like FILE_FLAG_POSIX_SEMANTICS, potentially causing portability issues for scripts or tools relying on such names. Authentication and security features present significant challenges, particularly on non-NT platforms like , where the absence of an NT-style security model prevents implementation of setuid and setgid bits, forcing reliance on Windows' impersonation that does not directly access encrypted passwords. On NT systems, while UWIN approximates Unix user/group permissions, programs like ftp and telnetd require modifications to handle Windows' differing authentication mechanisms, limiting seamless integration for security-sensitive applications. These constraints stem from fundamental differences in privilege models, as detailed in platform-specific implementations. Concurrency in multi-threaded applications is hampered by Win32 API mappings, including the inability to truncate memory-mapped files or rename directories containing open subdirectories, which can deadlock Unix processes expecting atomic operations. Socket handling further complicates matters, as Win32 lacks attributes for select() calls, requiring UWIN to use threads and events that may introduce race conditions in high-concurrency scenarios like network servers. UWIN does not replicate the full Unix kernel, notably lacking advanced signal handling and real-time extensions; signals from other processes are simulated via threads and events without direct kernel support, resulting in incomplete POSIX compliance for interrupt-driven or timing-critical code. Core Unix primitives like fork() and exec() are emulated through process spawning workarounds rather than native kernel calls, which reduces efficiency and fidelity for complex process management. The system's stability depends on the underlying Win32 , making UWIN vulnerable to changes in Windows updates that alter API behavior or deprecate features, necessitating ongoing adaptations for compatibility across Windows versions.

Compatibility issues

UWIN provides incomplete support for Unix applications that rely on kernel-level features, such as full device , as it implements special files like /dev/null and fifos using named pipes and shortcuts rather than native kernel mechanisms. This limitation affects applications requiring direct hardware access or advanced interactions, which cannot be fully emulated in user mode. Path handling in mixed Unix/Windows environments presents challenges despite the inclusion of UNC path support in version 1.3, which allows mapping Unix-style paths like /d/bin/date to Windows d:\bin\date. is managed through dual CreateFile() calls or reliance on the subsystem, but discrepancies arise in environments blending Unix and Windows file systems, potentially leading to resolution errors for paths with trailing dots or inconsistent naming conventions. Performance overhead occurs from DLL-based translations of Unix system calls to Win32 APIs, particularly in I/O-intensive tasks, as initial implementations of updates via server-based mechanisms incurred significant penalties before optimizations like writable shared segments were introduced. The has received no significant updates beyond version 1.3 from the late , and original resources are no longer available. A GitHub mirror of the codebase exists but shows no active maintenance as of November 2025. UWIN was specifically designed for and using the Win32 API. Compatibility with later versions such as and newer is unverified and unsupported due to the lack of ongoing development.
Add your contribution
Related Hubs
User Avatar
No comments yet.