RE: Win64-related patches
Michael Wookey wrote:
Michael Wookey wrote:
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim
- register', and watch it crash while trying to display an error
message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Well, that may fix it, but the problem is that the order of
initializations is violated. Normally all option pointers are not
NULL.
I think I've found it. In src/main.c:main(), the call to gui_prepare()
needs to occur after set_init_1() for two reasons:
1. set_init_1() ends up initialising the options table - and therefore
p_vfile.
2. The win32 implementation of gui_mch_prepare() as called from
gui_prepare() calls ole_error() in an error path. ole_error() calls
through to EMSG2() which eventually uses p_vfile. However since
gui_prepare() is called before set_init_1(), p_vfile has not yet been
initialised.
The attached patch demonstrates the solution by moving gui_prepare()
after set_init_1().
Changing the order of initializations is tricky. I would rather not do
this without extensive testing.
Isn't it much simpler to change ole_error() to invoke mch_errmsg()
instead of EMSG2()?
--
hundred-and-one symptoms of being an internet addict:
194. Your business cards contain your e-mail and home page address.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
RE: Win64-related patches
Hi Bram,
Michael Wookey wrote:
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -
register',
and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Well, that may fix it, but the problem is that the order of
initializations is violated. Normally all option pointers are not
NULL.
I think I've found it. In src/main.c:main(), the call to gui_prepare()
needs to occur after set_init_1() for two reasons:
1. set_init_1() ends up initialising the options table - and therefore
p_vfile.
2. The win32 implementation of gui_mch_prepare() as called from
gui_prepare() calls ole_error() in an error path. ole_error() calls
through to EMSG2() which eventually uses p_vfile. However since
gui_prepare() is called before set_init_1(), p_vfile has not yet been
initialised.
The attached patch demonstrates the solution by moving gui_prepare()
after set_init_1().
cheers
ole_register.patch
Description: ole_register.patch
RE: Win64-related patches
Hi Bram,
Michael Wookey wrote:
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim
-
register',
and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Well, that may fix it, but the problem is that the order of
initializations is violated. Normally all option pointers are not
NULL.
I think I've found it. In src/main.c:main(), the call to
gui_prepare()
needs to occur after set_init_1() for two reasons:
1. set_init_1() ends up initialising the options table - and therefore
p_vfile.
2. The win32 implementation of gui_mch_prepare() as called from
gui_prepare() calls ole_error() in an error path. ole_error() calls
through to EMSG2() which eventually uses p_vfile. However since
gui_prepare() is called before set_init_1(), p_vfile has not yet been
initialised.
The attached patch demonstrates the solution by moving gui_prepare()
after set_init_1().
I was over anxious! - attached is the correct patch. The gui_prepare()
must also appear before command_line_scan() so that the -register is
recognised.
cheers
ole_register_corrected.patch
Description: ole_register_corrected.patch
Re: Win64-related patches
On 12/02/2007 07:48, George V. Reilly wrote: * Win64 changes to make code compile cleanly: eval.c, misc2.c, if_ole.* * Fixed install.exe bug * Fixed annoying warning from Explorer about gvimext.dll * Fixed gvim.exe.mnf to be cross-platform. No longer needs to be generated from Make_mvc.mak * Re-fixed spell.c so that it works with VC6. Unit tests go into an infinite loop otherwise. * Updated INSTALLpc.txt to reflect that Visual C++ 2005 Express Edition is now free forever, recommending it over the VC 2003 Toolkit. * Cleaned up Make_mvc.mak, incorporating (and fixing) recent patches from Alexei Alexandrov and Mike Williams Last week's service pack for VS2005 has changed the nmake version number. It just needs the following three lines adding after the ones for the previous version for VS2005. !if $(_NMAKE_VER) == 8.00.50727.762 MSVCVER = 8.0 !endif I also had to edit make_mvc.mak for tests of MSVCVER as nmake did not like it enclosed in quotes. The expressions had to be of the form !if $(MSVCVER) == ... Since MSVCVER is set to a string the extra quotes end up being double double quotes which is invalid syntax. Should MSVCVER be set to string in the makefile? What do they come through as from the platform SDK? Apart from that all seems to work as expected. * Added mkdist.bat to copy all of the installable files to vim70 directory, where they are zipped up, for later installation on Win64 or Win32. * Made a futile attempt to get gvim.nsi building. Just building. Never mind running on Win64. * Fixed a bug in test60: test60.ok must have Unix line endings I have tested this code with the VS 98 (VC6), VS .NET 2003 (VC 7.1), VS 2003 Toolkit (VC 7.1), Visual Studio 2005 (VC8), Visual Studio 2005 Express Edition (VC 8), and the VS 2005 x64 cross-compiler. I'll re-test the Win64 binaries on a borrowed AMD64 machine at work tomorrow. As of yesterday, I was able to use install.exe to successfully install gvim and register gvimext.dll, giving the Edit with Vim entry in the Explorer context menu. Once everything is retested, I'll make fresh Win64 binaries available. One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -register', and watch it crash while trying to display an error message. Mike -- Sometimes a majority means that all the fools are on one side.
RE: Win64-related patches
Michael Wookey wrote:
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -
register',
and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Well, that may fix it, but the problem is that the order of
initializations is violated. Normally all option pointers are not
NULL.
What is the message that triggers this problem? That message should
probably be changed to mch_errmsg().
The actual error message wrapper is src/gui_w32:ole_error() which just
wraps EMSG2(). When calling gvim -register, the error propagates from
src/gui_w32.c:gui_mch_prepare().
I agree that the above patch fixes the symptom of the bug, but not the
true cause.
cheers
RE: Win64-related patches
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim
-register',
and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Re: Win64-related patches
George Reilly wrote: * Win64 changes to make code compile cleanly: eval.c, misc2.c, if_ole.* * Fixed install.exe bug * Fixed annoying warning from Explorer about gvimext.dll * Fixed gvim.exe.mnf to be cross-platform. No longer needs to be generated from Make_mvc.mak * Re-fixed spell.c so that it works with VC6. Unit tests go into an infinite loop otherwise. * Updated INSTALLpc.txt to reflect that Visual C++ 2005 Express Edition is now free forever, recommending it over the VC 2003 Toolkit. * Cleaned up Make_mvc.mak, incorporating (and fixing) recent patches from Alexei Alexandrov and Mike Williams * Added mkdist.bat to copy all of the installable files to vim70 directory, where they are zipped up, for later installation on Win64 or Win32. * Made a futile attempt to get gvim.nsi building. Just building. Never mind running on Win64. * Fixed a bug in test60: test60.ok must have Unix line endings I have tested this code with the VS 98 (VC6), VS .NET 2003 (VC 7.1), VS 2003 Toolkit (VC 7.1), Visual Studio 2005 (VC8), Visual Studio 2005 Express Edition (VC 8), and the VS 2005 x64 cross-compiler. I'll re-test the Win64 binaries on a borrowed AMD64 machine at work tomorrow. As of yesterday, I was able to use install.exe to successfully install gvim and register gvimext.dll, giving the Edit with Vim entry in the Explorer context menu. Once everything is retested, I'll make fresh Win64 binaries available. Great, thanks. I'll add this to the todo list and await comments. One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -register', and watch it crash while trying to display an error message. Should be easy to fix... -- hundred-and-one symptoms of being an internet addict: 108. While reading a magazine, you look for the Zoom icon for a better look at a photograph. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
