diff options
Diffstat (limited to 'runtime/doc/os_win32.txt')
| -rw-r--r-- | runtime/doc/os_win32.txt | 108 |
1 files changed, 3 insertions, 105 deletions
diff --git a/runtime/doc/os_win32.txt b/runtime/doc/os_win32.txt index a2ee0e1255..603dbcddce 100644 --- a/runtime/doc/os_win32.txt +++ b/runtime/doc/os_win32.txt @@ -7,8 +7,8 @@ *win32* *Win32* *MS-Windows* This file documents the idiosyncrasies of the Win32 version of Vim. -The Win32 version of Vim works on Windows NT, 95, 98, ME, XP, Vista and -Windows 7. There are both console and GUI versions. +The Win32 version of Vim works on Windows NT, XP, Vista and Windows 7. +There are both console and GUI versions. The 32 bit version also runs on 64 bit MS-Windows systems. @@ -37,23 +37,8 @@ The Win32 version was written by George V. Reilly <george@reilly.org>. The original Windows NT port was done by Roger Knobbe <RogerK@wonderware.com>. The GUI version was made by George V. Reilly and Robert Webb. -For compiling see "src/INSTALLpc.txt". *win32-compiling* - ============================================================================== -1. Known problems *windows95* *win32-problems* - -There are a few known problems with running in a console on Windows 95. As -far as we know, this is the same in Windows 98 and Windows ME. - -Comments from somebody working at Microsoft: "Win95 console support has always -been and will always be flaky". -1. Dead key support doesn't work. -2. Resizing the window with ":set columns=nn lines=nn" works, but executing - external commands MAY CAUSE THE SYSTEM TO HANG OR CRASH. -3. Screen updating is slow, unless you change 'columns' or 'lines' to a - non-DOS value. But then the second problem applies! - -If this bothers you, use the 32 bit MS-DOS version or the Win32 GUI version. +1. Known problems *win32-problems* When doing file name completion, Vim also finds matches for the short file name. But Vim will still find and use the corresponding long file name. For @@ -143,99 +128,12 @@ running under Win32s the following differences apply: ============================================================================== 6. Win32 mini FAQ *win32-faq* -Q. Why does the Win32 version of Vim update the screen so slowly on Windows 95? -A. The support for Win32 console mode applications is very buggy in Win95. - For some unknown reason, the screen updates very slowly when Vim is run at - one of the standard resolutions (80x25, 80x43, or 80x50) and the 16-bit DOS - version updates the screen much more quickly than the Win32 version. - However, if the screen is set to some other resolution, such as by ":set - columns=100" or ":set lines=40", screen updating becomes about as fast as - it is with the 16-bit version. - - WARNING: Changing 'columns' may make Windows 95 crash while updating the - window (complaints --> Microsoft). Since this mostly works, this has not - been disabled, but be careful with changing 'columns'. - - Changing the screen resolution makes updates faster, but it brings - additional problems. External commands (e.g., ":!dir") can cause Vim to - freeze when the screen is set to a non-standard resolution, particularly - when 'columns' is not equal to 80. It is not possible for Vim to reliably - set the screen resolution back to the value it had upon startup before - running external commands, so if you change the number of 'lines' or - 'columns', be very, very careful. In fact, Vim will not allow you to - execute external commands when 'columns' is not equal to 80, because it is - so likely to freeze up afterwards. - - None of the above applies on Windows NT. Screen updates are fast, no - matter how many 'lines' or 'columns' the window has, and external commands - do not cause Vim to freeze. - -Q. So if the Win32 version updates the screen so slowly on Windows 95 and the - 16-bit DOS version updates the screen quickly, why would I want to run the - Win32 version? -A. Firstly, the Win32 version isn't that slow, especially when the screen is - set to some non-standard number of 'lines' or 'columns'. Secondly, the - 16-bit DOS version has some severe limitations: It can't do big changes and - it doesn't know about long file names. The Win32 version doesn't have these - limitations and it's faster overall (the same is true for the 32-bit DJGPP - DOS version of Vim). The Win32 version is smarter about handling the - screen, the mouse, and the keyboard than the DJGPP version is. - -Q. And what about the 16-bit DOS version versus the Win32 version on NT? -A. There are no good reasons to run the 16-bit DOS version on NT. The Win32 - version updates the screen just as fast as the 16-bit version does when - running on NT. All of the above disadvantages apply. Finally, DOS - applications can take a long time to start up and will run more slowly. On - non-Intel NT platforms, the DOS version is almost unusably slow, because it - runs on top of an 80x86 emulator. - Q. How do I change the font? A. In the GUI version, you can use the 'guifont' option. Example: > :set guifont=Lucida_Console:h15:cDEFAULT < In the console version, you need to set the font of the console itself. You cannot do this from within Vim. -Q. When I change the size of the console window with ':set lines=xx' or - similar, the font changes! (Win95) -A. You have the console font set to 'Auto' in Vim's (or your MS-DOS prompt's) - properties. This makes W95 guess (badly!) what font is best. Set an explicit - font instead. - -Q. Why can't I paste into Vim when running Windows 95? -A. In the properties dialog box for the MS-DOS window, go to "MS-DOS - Prompt/Misc/Fast pasting" and make sure that it is NOT checked. You should - also do ":set paste" in Vim to avoid unexpected effects. |'paste'| - -Q. How do I type dead keys on Windows 95, in the console version? - (A dead key is an accent key, such as acute, grave, or umlaut, that doesn't - produce a character by itself, but when followed by another key, produces - an accented character, such as a-acute, e-grave, u-umlaut, n-tilde, and so - on. Very useful for most European languages. English-language keyboard - layouts don't use dead keys, as far as we know.) -A. You don't. The console mode input routines simply do not work correctly in - Windows 95, and I have not been able to work around them. In the words - of a senior developer at Microsoft: - Win95 console support has always been and will always be flaky. - - The flakiness is unavoidable because we are stuck between the world of - MS-DOS keyboard TSRs like KEYB (which wants to cook the data; - important for international) and the world of Win32. - - So keys that don't "exist" in MS-DOS land (like dead keys) have a - very tenuous existence in Win32 console land. Keys that act - differently between MS-DOS land and Win32 console land (like - capslock) will act flaky. - - Don't even _mention_ the problems with multiple language keyboard - layouts... - - You may be able to fashion some sort of workaround with the digraphs - mechanism. |digraphs| - - The best solution is to use the Win32 GUI version gvim.exe. Alternatively, - you can try one of the DOS versions of Vim where dead keys reportedly do - work. - Q. How do I type dead keys on Windows NT? A. Dead keys work on NT 3.51. Just type them as you would in any other application. |