doc: Remove refs to dos(16|32), win16, and win95

This is primarily low-hanging fruit; there are still many references to
things such as MS-DOS throughout (see os_dos.txt).
This commit is contained in:
Michael Reed 2015-06-27 19:10:16 -04:00
parent 5305338167
commit 36e3f4f4c4
9 changed files with 16 additions and 164 deletions

View File

@ -6722,8 +6722,6 @@ dialog_con Compiled with console dialog support.
dialog_gui Compiled with GUI dialog support.
digraphs Compiled with support for digraphs.
dnd Compiled with support for the "~ register |quote_~|.
dos16 16 bits DOS version of Vim.
dos32 32 bits DOS (DJGPP) version of Vim.
eval Compiled with expression evaluation support. Always
true, of course!
ex_extra Compiled with extra Ex commands |+ex_extra|.
@ -6824,12 +6822,10 @@ visualextra Compiled with extra Visual mode commands.
vreplace Compiled with |gR| and |gr| commands.
wildignore Compiled with 'wildignore' option.
wildmenu Compiled with 'wildmenu' option.
win16 Win16 version of Vim (MS-Windows 3.1).
win32 Win32 version of Vim (MS-Windows 95 and later, 32 or
64 bits)
win32unix Win32 version of Vim, using Unix files (Cygwin)
win64 Win64 version of Vim (MS-Windows 64 bit).
win95 Win32 version for MS-Windows 95/98/ME.
winaltkeys Compiled with 'winaltkeys' option.
windows Compiled with support for more than one window.
writebackup Compiled with 'writebackup' default on.

View File

@ -262,12 +262,6 @@ WARNING: If you close this window with the "X" button, and confirm the
question if you really want to kill the application, Vim may be killed too!
(This does not apply to commands run asynchronously with ":!start".)
In Windows 95, the window in which the commands are executed is always 25x80
characters, to be as DOS compatible as possible (this matters!). The default
system font is used. On NT, the window will be the default you have set up for
"Console" in Control Panel. On Win32s, the properties of the DOS box are
determined by _default.pif in the windows directory.
*msdos-mode*
If you get a dialog that says "This program is set to run in MS-DOS mode..."
when you run an external program, you can solve this by changing the

View File

@ -162,7 +162,7 @@ Versions ~
Remarks about specific systems ~
|os_mac.txt| Macintosh
|os_unix.txt| Unix
|os_win32.txt| MS-Windows 95/98/NT
|os_win32.txt| MS-Windows
*standard-plugin-list*
Standard plugins ~
|pi_getscript.txt| Downloading latest version of Vim scripts

View File

@ -360,9 +360,6 @@ cscope version for Win32 see:
http://iamphet.nm.ru/cscope/index.html
The DJGPP-built version from http://cscope.sourceforge.net is known to not
work with Vim.
Hard-coded limitation: doing a |:tjump| when |:cstag| searches the tag files
is not configurable (e.g., you can't do a tselect instead).

View File

@ -5461,17 +5461,7 @@ A jump table for the options with a short description can be found at |Q_op|.
"-f" is not inside the quotes, because it is not part of the command
name. And Vim automagically recognizes the backslashes that are path
separators.
For Dos 32 bits (DJGPP), you can set the $DJSYSFLAGS environment
variable to change the way external commands are executed. See the
libc.inf file of DJGPP.
Under MS-Windows, when the executable ends in ".com" it must be
included. Thus setting the shell to "command.com" or "4dos.com"
works, but "command" and "4dos" do not work for all commands (e.g.,
filtering).
For unknown reasons, when using "4dos.com" the current directory is
changed to "C:\". To avoid this set 'shell' like this: >
:set shell=command.com\ /c\ 4dos
< This option cannot be set from a |modeline| or in the |sandbox|, for
This option cannot be set from a |modeline| or in the |sandbox|, for
security reasons.
*'shellcmdflag'* *'shcf'*

View File

@ -87,15 +87,15 @@ key key code Normal/Visual mode Insert mode ~
CTRL-PageUp <M-N><M-C-D> H <C-O>H
CTRL-PageDown <M-N>v L$ <C-O>L<C-O>$
Additionally, these keys are available for copy/cut/paste. In the Win32
and DJGPP versions, they also use the clipboard.
Additionally, these keys are available for copy/cut/paste.
In the Win32 version, they also use the clipboard.
Shift-Insert paste text (from clipboard) *<S-Insert>*
CTRL-Insert copy Visual text (to clipboard) *<C-Insert>*
CTRL-Del cut Visual text (to clipboard) *<C-Del>*
Shift-Del cut Visual text (to clipboard) *<S-Del>*
These mappings accomplish this (Win32 and DJGPP versions of Vim):
These mappings accomplish this (Win32 version of Vim):
key key code Normal Visual Insert ~
Shift-Insert <M-N><M-T> "*P "-d"*P <C-R><C-O>*
@ -276,18 +276,14 @@ If you are running a third-party shell, you may need to set the
|'shellcmdflag'| ('shcf') and |'shellquote'| ('shq') or |'shellxquote'|
('sxq') options. Unfortunately, this also depends on the version of Vim used.
For example, with the MKS Korn shell or with bash, the values of the options
should be:
on Win32 should be:
DOS 16 bit DOS 32 bit Win32 ~
'shellcmdflag' -c -c -c
'shellquote' "
'shellxquote' "
'shellcmdflag' -c
'shellquote' (empty)
'shellxquote' "
For Dos 16 bit this starts the shell as:
<shell> -c "command name" >file
For Win32 as:
For Win32, this starts the shell as:
<shell> -c "command name >file"
For DOS 32 bit, DJGPP does this internally somehow.
When starting up, Vim checks for the presence of "sh" anywhere in the 'shell'
option. If it is present, Vim sets the 'shellcmdflag' and 'shellquote' or

View File

@ -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.

View File

@ -1519,8 +1519,6 @@ patches by Mathias, see mail Feb 22)
Win32: compiling with normal features and OLE fails. Patch by Mathias
Michaelis, 2006 Jun 4.
Win16: include patches to make Win16 version work. (Vince Negri, 2006 May 22)
Win32: after "[I" showing matches, scroll wheel messes up screen. (Tsakiridis,
2007 Feb 18)
Patch by Alex Dobrynin, 2007 Jun 3. Also fixes other scroll wheel problems.
@ -2088,14 +2086,6 @@ MSDOS and Win32:
backslashes. (Ronald Hoellwarth)
Windows 95:
8 Editing a file by its short file name and writing it, makes the long file
name disappear. Setting 'backupcopy' helps.
Use FindFirstFile()->cAlternateFileName in fname_case() (George Reilly).
8 Doing wildcard expansion, will match the short filename, but result in the
long filename (both DJGPP and Win32).
Win32 console:
9 When editing a file by its short file name, it should be expanded into its
long file name, to avoid problems like these: (Mccollister)
@ -2261,9 +2251,6 @@ Macintosh:
one for B&W printing (if that can be detected).
8 In Visual block mode with 'lbr' set, a change command doesn't insert the
text in following lines where the linebreak changes.
9 dosinst.c: The DJGPP version can't uninstall the Uninstall registry key on
Windows NT. How to install a .inf file on Windows NT and how to detect
that Windows NT is being used?
8 When 'virtualedit' is "block,insert" and encoding is "utf-8", selecting a
block of one double-wide character, then "d" deletes only half of it.
8 When 'virtualedit' is set, should "I" in blockwise visual mode also insert
@ -2438,7 +2425,7 @@ Problems that will (probably) not be solved:
- Win32: All files created on the day of switching from winter to summer
time cause "changed since editing started" messages. It goes away when
the file is written again the next day, or the timezone is adjusted.
DJGPP version is OK. (Zaimi) Looks like a problem with the Win32 library.
Looks like a problem with the Win32 library.
Rebooting doesn't help. Time stamps look OK in directory. (Penn)
Is this on FAT (stores wall clock time) or NTFS (stores UTS)?
- Win32, MS-Windows XP: $HOME uses the wrong drive when the user profiles
@ -3151,8 +3138,6 @@ Performance:
8 When displaying a space with only foreground highlighting, it's the same
as a space without attributes. Avoid displaying spaces for the "~" lines
when starting up in a color terminal.
8 Avoid alloc() for scratch buffer use, esp. in syntax.c. It's very slow on
Win16.
8 Profiling shows that in_id_list() is used very often for C code. Can this
function be improved?
8 For an existing file, the page size of the swap file is always the

View File

@ -2992,12 +2992,8 @@ void ex_checktime(exarg_T *eap)
static char *get_locale_val(int what)
{
char *loc;
/* Obtain the locale value from the libraries. For DJGPP this is
* redefined and it doesn't use the arguments. */
loc = setlocale(what, NULL);
// Obtain the locale value from the libraries.
char *loc = setlocale(what, NULL);
return loc;
}