1 / 31

WINE

WINE. Windows NT Architecture. WINE Architecture. socket. pipe. Wine Directory Structure. server/ wineserver Windows abstract object (mailslot, mutex, … etc) dlls/ Windows DLL loader/ Wine call a preloader to reserve memory space for Windows application. Wine Overview. Windows App.

xanto
Download Presentation

WINE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WINE

  2. Windows NT Architecture

  3. WINE Architecture socket pipe

  4. Wine Directory Structure • server/ • wineserver • Windows abstract object (mailslot, mutex, … etc) • dlls/ • Windows DLL • loader/ • Wine call a preloader to reserve memory space for Windows application

  5. Wine Overview Windows App wineserver Windows EXE Kernel32.DLL socket NTDLL.DLL pipe • Client send request to wineserver through the pipe • winserver poll request then call corresponding handler

  6. Load Windows Binary - Part 1 • Example • wine → wine_preloader → wine → notepad.exe • They are the same process but with different image • wine check a environment variable too see if preloader already ran before, and when wine_preloader finish its job, it reload wine image and start to load Windows application (i.e., notepad.exe)

  7. Load Windows Binary - Part 1 • wine_preloader • Use customized entry function _start • _start call wld_start to reserve memory space for Windows PE binary, then jump to dynamic linker return by wld_start

  8. Load Windows Binary - Part 2 • Since preloader already ran, we are ready to start the real and complicate job • wine → wine_preloader → wine → notepad.exe

  9. Load Windows Binary - Part 2 • wine → wine_init • wine_init → __wine_process_init (NTDLL.DLL) • __wine_process_init →__wine_kernel_init (Kernel32.DLL) • __wine_kernel_init → start_process • start_process → notepad.exe

  10. Load Windows Binary - Part 2 • wine_init (libs/wine/loader.c) • Set up DLL path so that wine can load correct DLL it want • Load built-in NTDLL.DLL. Built-in DLL contains standard WinAPI and wine internal functions • Get address of function __wine_process_init from built-in BTDLL.DLL • Run __wine_process_init

  11. Load Windows Binary - Part 2 • wine_process_init(dlls/ntdll/loader.c) • Call function thread_init to initialize TEB, PEB and other environment for Windows application. Launch winserver if needed and set up connection to the winserver • Load built-in Kernel32.DLL • Get address of function __wine_kernel_init from built-in Kernel32.DLL

  12. Load Windows Binary - Part 2 • wine_kernel_init • Initialize things like register this Windows application to wineserver, set up current directory and environment parameters • Load image of Windows application

  13. Load Windows Binary - Part 2 • start_process • LdrInitializeThunk loads remaining DLL needed by the target Windows application • Jump to Windows application entry point and kick off • All WinAPI called by Windows application will be directed to Wine’s version

  14. Implement Win32/NT API • Three examples • CreateProcess • OpenFile • WriteFile • Most of them are implement through POSIX API with emulation • Some of them call POSIX API at client side, others are at wineserver side

  15. CreateProcess Windows App wineserver CreateProcessW (dlls/kernel32/process.c) create_process_impl (dlls/kernel32/process.c) create_process (dlls/kernel32/process.c) req_new_process (server/process.c) create_process (server/process.c) exec_loader (dlls/kernel32/process.c) fork →wine_exec_wine_binary

  16. OpenFile Windows App wineserver OpenFile (dlls/kernel32/file.c) req_create_file (server/file.c) create_file (server/file.c) NtCreateFile (dlls/ntdll/file.c) struct fd *open_fd (server/fd.c) FILE_CreateFile (dlls/ntdll/file.c) fd->unix_fd = open( … ); reply->handle = alloc_handle( … );

  17. File • Windows app does not own the file it creates by using WinAPI like OpenFile/CreateFile • OpenFile/CreateFile send request to wineserver • wineserver uses open to create a UNIX file descriptor, associated it with <windows process, handle> pair • Windows app only see a fake Windows file handle returned by wineserver

  18. WriteFile Windows App wineserver WriteFile (dlls/kernel32/file.c) req_get_handle_fd (server/fd.c) NtWriteFile (dlls/ntdll/file.c) get_handle_fd_obj (server/fd.c) server_get_unix_fd (dlls/ntdll/server.c) send_client_fd (server/request.c) receive_fd (dlls/ntdll/server.c) write(fd …);

  19. WriteFile Windows App wineserver wineserver gives the file descriptor access right temporarily User space Kernel space file

  20. Cygwin

  21. Cygwin Overview C library which provides a POSIX-style API

  22. Cygwin Overview UNIX App cygwin1.dll newlibc (C runtime) Kernel32.DLL NTDLL.DLL

  23. What Cygwin Is? • Cygwin includes two parts • Provide tools like gcc, make, … etc, let you compile UNIX source code into Windows executable • Provide cygwin1.dll which acts as a Linux API layer on Windows

  24. fork fork (cygwin/fork.cc) frok:: parent (cygwin/fork.cc) CreateProcessW (Win32 API) • Win32 API receive more parameters then POSIX API, make up those • parameters

  25. open • UNIX provides uniform interfaces like open/close/read/write to access devices • Windows provides various interfaces for different devices • cygwin glue them by using Class fhandler_base open (cygwin/syscalls.cc) build_fh_name (cygwin/dtable.cc)

  26. open • cygwin glue them by providing a abstract layer: class fhandler_base virtual int ioctl (unsigned int cmd, void *); virtual int fcntl (int cmd, void *); virtual char const *ttyname () { return get_name (); } virtual void __stdcall read (void *ptr, size_t& len) __attribute__ ((regparm (3))); virtual ssize_t __stdcall write (const void *ptr, size_t len);

  27. open • cygwin glue them by providing a abstract layer: class fhandler_base virtual int ioctl (unsigned int cmd, void *); virtual int fcntl (int cmd, void *); virtual char const *ttyname () { return get_name (); } virtual void __stdcall read (void *ptr, size_t& len) __attribute__ ((regparm (3))); virtual ssize_t __stdcall write (const void *ptr, size_t len);

  28. open open (cygwin/syscalls.cc) build_fh_name (cygwin/dtable.cc) fhandler_disk_file::open (cygwin/ fhandler_disk_file.cc) NtCreateFile fhandler_base::open_fs (cygwin/ fhandler_disk_file.cc) fhandler_base::open (cygwin/fhandler.cc) Need to deal with different path convention between UNIX and Windows

  29. Design & Implementation Strategy • Both WINE and Cygwin are API compatibility layers, WinAPI-to-POSIX or vise versa (with a little different) • WINE provides binary level compatibility • You don’t have to compile Windows source code • Since you usually can’t get the source code • Cygwin provides source level compatibility • You use GCC (Windows port) provided by Cygwin to compile UNIX source code

  30. Design & Implementation Strategy • Both implement their own .so or DLL, which do API conversion, or vise versa • Wine need to implement its own PE loader/dynamic linker, since it achieve binary level compatibility

  31. Goal • Thedesign and implementation strategy of these systems • The whole procedure from inputting guest app all the way to generating the host code • One process management example • One memory management example (or file system, network, device) to explain the procedure

More Related