Tony Mechelynck wrote:

> Even after "make reconfig" (which did not happen spontaneously), the
> latest Vim 7.3 installs its runtimes in $VIM/vim73d but looks for them
> in $VIM/vim73c (:version displays "VIM - Vi IMproved 7.3c BETA").
>
> Is there a conflict between the src/Makefile and the version.h ?
>
> src/version.h line 36:
> #define VIM_VERSION_NODOT "vim73c"
>
> src/Makefile line 933
> VIMMINOR = 3d

Right, I forgot to update src/version.h.  Done now.

--
You can test a person's importance in the organization by asking how much RAM
his computer has.  Anybody who knows the answer to that question is not a
decision-maker.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- 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    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 31-Jul-2010 Tony Mechelynck wrote:
> On 19/07/10 00:25, Tony Mechelynck wrote:
[...]
> >(after creating a "first tab" with many windows in it, then several
> >additional tabs with one window each), however when clearing the intro
> >screen after startup (e.g. by hitting the spacebar) I am in the top
> >window, not in the 2nd from bottom. The same happened with the two
> >:wincmd lines above replaced by the single
[...]
>
> I don't know exactly when, but the problem has disappeared.
>
> Best regards,
> Tony.

It was with the latest plugin/netrwPlugin.vim update.

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01/08/10 22:51, Lech Lorens wrote:
> On 31-Jul-2010 Tony Mechelynck wrote:
>> On 19/07/10 00:25, Tony Mechelynck wrote:
> [...]
>>> (after creating a "first tab" with many windows in it, then several
>>> additional tabs with one window each), however when clearing the intro
>>> screen after startup (e.g. by hitting the spacebar) I am in the top
>>> window, not in the 2nd from bottom. The same happened with the two
>>> :wincmd lines above replaced by the single
> [...]
>>
>> I don't know exactly when, but the problem has disappeared.
>>
>> Best regards,
>> Tony.
>
> It was with the latest plugin/netrwPlugin.vim update.
>

hm...
hg log -f runtime/plugin/netrwPlugin.vim --style changelog
hg diff -r 6de9efd58dc0 -r e52d87a2bb3e runtime/plugin/netrwPlugin.vim

Ah, I see it now, in the 2nd hunk.

Would never have guessed that my only remote buffer (in a different tab)
was the culprit.


Best regards,
Tony.
--
A parent can be arrested if his child cannot hold back a burp during a
church
service.
		 [real standing law in Nebraska, United States of America]

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 01-Aug-2010 Tony Mechelynck <antoine.mechelynck@...> wrote:
> hm...
> hg log -f runtime/plugin/netrwPlugin.vim --style changelog
> hg diff -r 6de9efd58dc0 -r e52d87a2bb3e runtime/plugin/netrwPlugin.vim
>
> Ah, I see it now, in the 2nd hunk.
>
> Would never have guessed that my only remote buffer (in a different
> tab) was the culprit.

It was probably not. I had a similar problem when trying to execute
a "session file" which opened two local files.

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Hi

Vim-7.3d (2467:7f578da7edb2) accesses uninitialized memory when
encrypting an empty buffer with cryptmethod=blowfish:

$ valgrind --num-callers=50 --track-origins=yes --log-file=/tmp/vg.log \
   vim -u NONE -N -c 'set cm=blowfish' \
     -c 'call feedkeys(":X\<CR>foo\<CR>foo\<CR>:sav! /tmp/foo\<CR>")'

... and /tmp/vg.log contains:

==6126== Use of uninitialised value of size 4
==6126==    at 0x805C630: bf_e_block (blowfish.c:340)
==6126==    by 0x805CCAB: bf_e_cblock (blowfish.c:385)
==6126==    by 0x805D20E: bf_crypt_encode (blowfish.c:611)
==6126==    by 0x811AFC9: crypt_encode (misc2.c:3868)
==6126==    by 0x80FDFFB: ml_encrypt_data (memline.c:4849)
==6126==    by 0x80F6422: mf_write_block (memfile.c:1165)
==6126==    by 0x80F632D: mf_write (memfile.c:1121)
==6126==    by 0x80F59A4: mf_sync (memfile.c:599)
==6126==    by 0x80FA11D: ml_preserve (memline.c:2330)
==6126==    by 0x80C8919: buf_write (fileio.c:4160)
==6126==    by 0x809832D: do_write (ex_cmds.c:2706)
==6126==    by 0x8097DF0: ex_write (ex_cmds.c:2519)
==6126==    by 0x80A85C8: do_one_cmd (ex_docmd.c:2656)
==6126==    by 0x80A5EA1: do_cmdline (ex_docmd.c:1122)
==6126==    by 0x812E54B: nv_colon (normal.c:5319)
==6126==    by 0x8127BE7: normal_cmd (normal.c:1190)
==6126==    by 0x80E8ECF: main_loop (main.c:1260)
==6126==    by 0x80E8904: main (main.c:965)
==6126==  Uninitialised value was created by a heap allocation
==6126==    at 0x4024F70: malloc (vg_replace_malloc.c:236)
==6126==    by 0x8117E4E: lalloc (misc2.c:920)
==6126==    by 0x8117D3E: alloc (misc2.c:818)
==6126==    by 0x80F4F79: mf_open (memfile.c:133)
==6126==    by 0x80F68D7: ml_open (memline.c:311)
==6126==    by 0x8053830: open_buffer (buffer.c:93)
==6126==    by 0x80EABB0: create_windows (main.c:2597)
==6126==    by 0x80E8598: main (main.c:809)
(and more errors after that)

It happens with 'cm=blowfish' but not with 'cm=zip'.
I have not found the fix yet.

Regards
-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

g++-3 -shared -O2 -mno-cygwin -s -o gvimext.dll \
                  -Wl,--enable-auto-image-base \
                  -Wl,--enable-auto-import \
                  -Wl,--whole-archive \
                          gvimext.o gvimext.res gvimext_ming.def \
                  -Wl,--no-whole-archive \
                          -L/lib/w32api -luuid
[...]/AppData/Local/Temp/ccISkFaJ.o:uninstal.c:(.text+0x44a): undefined
reference to `_RegDeleteKeyEx'
[...message repeats...]
collect2: ld returned 1 exit status
make: *** [uninstal.exe] Error 1

- Christian

--
Christian J. Robinson <heptite@...> -- http://christianrobinson.name/

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Oops, the subject should have been uninstal.c, not gvimext.dll

--
Christian J. Robinson <heptite@...> -- http://christianrobinson.name/

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 8/01/10 7:46 PM, Christian J. Robinson wrote:
>
> Oops, the subject should have been uninstal.c, not gvimext.dll
>
The problem is that WINVER is defined as 0x0400 in Make_ming.mak and
RegKeyDeleteEx is only available with WINVER 0x0502 and above.

Chris

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar <Bram@...> wrote:
> I have included the recent patches, but not the one that resets
> "recursive" in gen_expand_wildcards().  That is probably causing that
> crash.

I noticed that mch_expandpath() is defined on both unix and windows as
unix_expandpath() and dos_expandpath(), respectively.  I'll see if it
can be used in place of globpath() (which calls gen_expand_wildcards())
  in the function expand_in_path().

If that is successful I'll send a new patch for that and also revert thechanges
I did in globpath() (skipping url path).

In the mean time here is the patch to prevent ":find <tab>" from crashing on
windows when 'path" is set to something like "c:\src\**".

nazri.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Sun, 1 Aug 2010, Chris Sutcliffe wrote:

> On 8/01/10 7:46 PM, Christian J. Robinson wrote:
>>
>> Oops, the subject should have been uninstal.c, not gvimext.dll
>>
> The problem is that WINVER is defined as 0x0400 in Make_ming.mak and
> RegKeyDeleteEx is only available with WINVER 0x0502 and above.

I'm using Make_cyg.mak, but the same holds true there.  I changed it
to 0x0502 and the error disappeared.

Thank you.

- Christian

--
Christian J. Robinson <heptite@...> -- http://christianrobinson.name/

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

I found the 7.3d NSIS installer I built cannot uninstall Vim on
Windows XP SP3.  When I replicate the uninstallation process
manually, the following error was reported when launch
"uninstal.exe":

     Entry Point Not Found:
     The procedure entry point RegDeleteKeyExA could not be located
     in the dynamic link library ADVAPI32.DLL.

It turns out RegDeleteKeyEx() is only available on 64 bit Windows,
according to MSDN:
     http://msdn.microsoft.com/en-us/library/ms724847(VS.85).aspx
Minimum supported client:
     Windows Vista, Windows XP Professional x64 Edition

That function call was introduced in changeset b204ac54bea4:
     Fix: the MS-Windows uninstaller did not delete registry keys on
     64 bit systems.

The simple patch (against changeset 7f578da7edb2) I attached defines
a macro REG_DELETE_KEY, which translates to RegDeleteKeyEx when
WIN3264 defined, and to RegDeleteKey otherwise.

I only tested the patch on Windows XP SP3, it works.  I do not have
64-bit system to verify with, it should work in theory since the
code is the same after pre-processing when WIN3264 is defined.

Regards!

--
Guopeng

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

> It has already been included in vim73 branch (on July 30).
> See:
>
> $ hg diff -c c587f56735cc

My runtime files were not updated
So I mistook that, sorry.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Mon, Aug 2, 2010 at 8:49 AM, Nazri Ramliy <ayiehere@...> wrote:
> On Thu, Jul 29, 2010 at 4:39 AM, Bram Moolenaar <Bram@...> wrote:
>> I have included the recent patches, but not the one that resets
>> "recursive" in gen_expand_wildcards().  That is probably causing that
>> crash.
>
> I noticed that mch_expandpath() is defined on both unix and windows as
> unix_expandpath() and dos_expandpath(), respectively.  I'll see if it
> can be used in place of globpath() (which calls gen_expand_wildcards())
>  in the function expand_in_path().
>
> If that is successful I'll send a new patch for that and also revert
thechanges
> I did in globpath() (skipping url path).

It turned out that using unix_expandpath() for find completion is much,
much slower than using globpath.  I ended up using mch_expandpath only when
WIN3264 is defined, and use globpath() otherwise.

The benchmark result (doing a find completion for "jingle.gy" in the google
chrome source code, the fullname is "jingle.gyp"):

bench.vim:
---->8----
:set path=~/src/chrome/**
:find jingle.gy
:q

----8<----
Note: there's a single tab character after jingle.gy

Result of running

   $ time ./vim-globpath -s bench.vim; time ./vim-mch_expandpath -s bench.vim

for five consecutive runs (whitespaces added to align the timing output below):

./vim-globpath       -s bench.vim  0.48s user 1.90s system 92% cpu 2.570 total
./vim-mch_expandpath -s bench.vim  4.26s user 3.97s system 90% cpu 9.135 total

./vim-globpath       -s bench.vim  0.53s user 1.64s system 93% cpu 2.310 total
./vim-mch_expandpath -s bench.vim  2.62s user 2.03s system 91% cpu 5.077 total

./vim-globpath       -s bench.vim  0.46s user 1.80s system 91% cpu 2.475 total
./vim-mch_expandpath -s bench.vim  3.39s user 3.10s system 86% cpu 7.471 total

./vim-globpath       -s bench.vim  0.44s user 1.47s system 88% cpu 2.153 total
./vim-mch_expandpath -s bench.vim  2.00s user 1.92s system 90% cpu 4.350 total

./vim-globpath       -s bench.vim  0.47s user 1.46s system 84% cpu 2.271 total
./vim-mch_expandpath -s bench.vim  2.59s user 2.41s system 96% cpu 5.185 total

Based on the benchmark result above it appears that using globpath() is about
4 times faster than using mch_expandpath() for doing find completion.

Attached patch makes find completion works on windows using mch_expandpath().
On unix we still use globpath().  This is done checking #if defined(WIN3264),
I'm not sure if that is the preferred way to detect if we're compiling on
windows.

> In the mean time here is the patch to prevent ":find <tab>" from crashing on
> windows when 'path" is set to something like "c:\src\**".

With the attached patch the above is no longer necessary.

For people who would like to test this out, please note the remark in :help
'path':

         - Careful with '\' characters, type two to get one in the option:
                 :set path=.,c:\\include
           Or just use '/' instead: >
                 :set path=.,c:/include

For example use ":set path=.,c:\\include\\**" or ":set path=.,c:/include/**"
to make vim recursively find completion candidates in c:\include directory.

nazri.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

A recent change to uninstal.c breaks building Vim on 32-bit Windows.

These changes:
hg diff -r 573da4dac306:b204ac54bea4 src/uninstal.c

involve replacing RegDeleteKey with RegDeleteKeyEx

Problem occurs with Windows XP 32-bit, using MS Visual C 6.0, command:
nmake -f Make_mvc.mak

Build stops at:
uninstal.obj : error LNK2001: unresolved external symbol _RegDeleteKeyEx

I think RegDeleteKeyEx requires Vista or later, or XP x64.
I don't need uninstal, but it breaks the build.

John

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

John Beckett wrote:

> A recent change to uninstal.c breaks building Vim on 32-bit Windows.
>
> These changes:
> hg diff -r 573da4dac306:b204ac54bea4 src/uninstal.c
>
> involve replacing RegDeleteKey with RegDeleteKeyEx
>
> Problem occurs with Windows XP 32-bit, using MS Visual C 6.0, command:
> nmake -f Make_mvc.mak
>
> Build stops at:
> uninstal.obj : error LNK2001: unresolved external symbol _RegDeleteKeyEx
>
> I think RegDeleteKeyEx requires Vista or later, or XP x64.
> I don't need uninstal, but it breaks the build.

I don't think this depends on the OS but on the compiler.  I'm building
Vim fine on Windows XP.  That is with MSVC 2010.

We could solve this with a few #ifdefs, I suppose.  But it will mean
that the binary you build with older MSVC won't install/uninstall
properly on 64 bit systems.  We should somehow give a warning about
this and suggest using a newer compiler.

For that #ifdef we need to know which compiler supports the new
function.

--
I recommend ordering large cargo containers of paper towels to make up
whatever budget underruns you have.  Paper products are always useful and they
have the advantage of being completely flushable if you need to make room in
the storage area later.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- 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    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Bram wrote:
>> Build stops at:
>> uninstal.obj : error LNK2001: unresolved external symbol
>> _RegDeleteKeyEx
>>
>> I think RegDeleteKeyEx requires Vista or later, or XP x64.
>> I don't need uninstal, but it breaks the build.
>
> I don't think this depends on the OS but on the compiler.
> I'm building Vim fine on Windows XP.  That is with MSVC 2010.
>
> We could solve this with a few #ifdefs, I suppose.  But it
> will mean that the binary you build with older MSVC won't
> install/uninstall properly on 64 bit systems.  We should
> somehow give a warning about this and suggest using a newer compiler.
>
> For that #ifdef we need to know which compiler supports the
> new function.

Hmmm. But if installing a newer compiler fixed the problem, that
would simply mean that I had installed some library with
RegDeleteKeyEx, so the link would be ok. However, the resulting
uninstal.exe would not run on other systems without that special
library.

Googling for 'RegDeleteKeyEx win32' (no quotes) finds lots of
hits, including:

http://msdn.microsoft.com/en-us/library/ms724847%28VS.85%29.aspx
http://stackoverflow.com/questions/1476749/how-do-i-delete-a-registry-entry-in-w\
indows-x64-in-the-64-bit-tree-without-using

The first seems to be the official docs, and it says that
RegDeleteKeyEx requires Vista or later, or XP x64.

The second is a question on exactly the uninstal.c problem: how
can an executable run on Windows XP or later, including 64 bit
systems, and remove certain registry entries. The ugly
suggestion is to load the function dynamically, after
determining the runtime environment.

Perhaps you could make a macro in uninstal.c: #ifdef _WIN64
then use RegDeleteKeyEx, otherwise user RegDeleteKey.
As you say, an exe built on 32 bit would run only on 32 bit.

John

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Jul 28, 3:55 pm, Charles Campbell wrote:
>
> I've put a new syntax/tex.vim on my website (and have given it to Bram
> for inclusion in 7.3).  You may try it out by getting it
fromhttp://mysite.verizon.net/astronaut/vim/index.html#vimlinks_syntaxand
> clicking ontex.vim.gz .  Of course you'll need a gunzip or similar tool
> on Windows to decompress the file.
>
> The newtexsyntax file supports setting conceallevel to 2 with utf-8 by
> showing appropriate glyphs for Greek in math, a few math symbols in
> math, and a number of accented characters.
>
> I personally have little call to use accents in my writing, so I may
> well have missed some "favorites".  If you'd like some accented
> character that syntax/tex.vim is presently missing, please send me a
> line or two of the form
>
>    syn match texAccent    '\\c{c}'    conceal cchar=
>
> where the '\\c{c}', for example, shows a Vim regex pattern matching the
> LaTeX \c{c} which causes to appear.  To find the utf-8 glyphs, you may
> wish to refer tohttp://www.utf8-chartable.de/unicode-utf8-table.pl.  
> You can find my email address at the 3rd line of  vim73c/syntax/tex.vim .

Hi Chip (and vim_dev),

I really like the idea of using conceal in the tex syntax file but it
still needs some work (I'm basing my comments on the version of
tex.vim that was included in the Sun 1 Aug changeset).

Try the following:

   $\eps_b \geq \rho^{-\sigma b}$

- Super/subscripts look weird.  The \sigma is typeset as superscript
"s i g m a" (each letter is a superscript).  As it stands I'd rather
have no super/subscripts at all than this weird behavior.  (In fact, I
dislike the super/subscripts anyway because they become so tiny that
they are hard to read unless you set your 'gfn' size to something
enormous.)

- Super/subscripts work inconsistently.  Note that the "_b" after
"\eps" is not turned into a subscript.  As far as I understand some
letters are not available as subscripts?  Again, I'd rather have no
subscripts at all than to have some letters turn into subscripts but
not others.

- $, { and } are turned into "-".  Why?

- I can think of a few more things to conceal (off the top of my
head): \infty, \in, \subset (and variants), \cup, \cap, \wedge, \vee,
the list goes forever on (it may be helpful to take a look at "short-
math-guide.pdf" by Michael Downes)


Anyway, I am grateful for the work you've put into this but there is
definitely room for improvement (my apologies for not simply sending
you a patch but I really should get back to writing that
article... ;-).


Björn

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Le Mon, 2 Aug 2010 21:25:05 +1000, John Beckett a écrit dans le message
<2504DC3D77FA4577B217BAC5971D1CE6@quartz> :

> Perhaps you could make a macro in uninstal.c: #ifdef _WIN64
> then use RegDeleteKeyEx, otherwise user RegDeleteKey.
> As you say, an exe built on 32 bit would run only on 32 bit.

RegDeleteKeyEx was used in 7.2 (macro #ifdef WIN3264) and I can build
7.3b on Win98 using Borland Bcc.

In 7.3c KEY_ALL_ACCESS parameter is replaced by KEY_WOW64_64KEY |
KEY_ALL_ACCESS. See :
<ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.3b-7.3c.diff.gz>

I will try to build this version.

--
Patrick Texier

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 8/02/10 6:28 AM, Bram Moolenaar wrote:
> I don't think this depends on the OS but on the compiler. I'm building
> Vim fine on Windows XP.  That is with MSVC 2010.
>
> We could solve this with a few #ifdefs, I suppose.  But it will mean
> that the binary you build with older MSVC won't install/uninstall
> properly on 64 bit systems.  We should somehow give a warning about
> this and suggest using a newer compiler.

As I mentioned on the Vim Use mailing list, for MinGW (and Cygwin) at
least, RegDeleteKeyEx is defined for WINVER >= 0x0502 (Windows XP), but
the Make_ming.mak file (and apparently Make_cyg.mak) define WINVER as
0x0400, so RegDeleteKeyEx is undefined unless that value is adjusted.

A simple fix for Cygwin and MinGW would be to change the WINVER value in
the corresponding makefiles.

Chris

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Mon, 02 Aug 2010 15:16:07 +0200, I wrote:

> RegDeleteKeyEx was used in 7.2 (macro #ifdef WIN3264) and I can build
> 7.3b on Win98 using Borland Bcc.

> In 7.3c KEY_ALL_ACCESS parameter is replaced by KEY_WOW64_64KEY |
> KEY_ALL_ACCESS. See :
> <ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.3b-7.3c.diff.gz>

> I will try to build this version.

Yes, I have errors with KEY_WOW64_64KEY in if_ole.cpp 7.3c:

c:\borland\bcc55\BIN\Bcc32 +WIN32\oleobj\bcc.cfg -c -oWIN32\oleobj\if_ol
e.obj if_ole.cpp
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
if_ole.cpp:
Error E2451 if_ole.cpp 161: Undefined symbol 'KEY_WOW64_64KEY' in
function CVim::Create(int *)
Error E2451 if_ole.cpp 654: Undefined symbol 'KEY_WOW64_64KEY' in
function RecursiveDeleteKey(HKEY__ *,const char *)
Error E2451 if_ole.cpp 697: Undefined symbol 'KEY_WOW64_64KEY' in
function SetKeyAndValue(const char *,const char *,const char *)
*** 3 errors in Compile ***

** error 1 ** deleting WIN32\oleobj\if_ole.obj
--
Patrick Texier

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

I'm getting following error:

--------------------
gcc ... -o uninstal.exe uninstal.c -lkernel32 -luser32 -lgdi32
-ladvapi32 -lcomdlg32 -lcomctl32 -lversion -lwsock32 -Lc:/tcl/lib
-ltclstub85
C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x24):
undefined reference to `RegDeleteKeyEx'
C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x4f):
undefined reference to `RegDeleteKeyEx'
C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x79):
undefined reference to `RegDeleteKeyEx'
C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xa3):
undefined reference to `RegDeleteKeyEx'
C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xcd):
undefined reference to `RegDeleteKeyEx'
C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xf7): more
undefined references to `RegDeleteKeyEx' follow
collect2: ld returned 1 exit status
make: *** [uninstal.exe] Error 1
--------------------

Many thanks in advance,

--
Cesar

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Mon, 02 Aug 2010 15:41:48 +0200, I wrote:

> > I will try to build this version.

> Yes, I have errors with KEY_WOW64_64KEY in if_ole.cpp 7.3c:

#define is missing. I can build Vim 7.3c with bcc on Win98 using
attached patch.
--
Patrick Texier

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 02/08/2010 08:55 a.m., Cesar Romani wrote:
  > I'm getting following error:
  >
  > --------------------
  > gcc ... -o uninstal.exe uninstal.c -lkernel32 -luser32 -lgdi32
  > -ladvapi32 -lcomdlg32 -lcomctl32 -lversion -lwsock32 -Lc:/tcl/lib
  > -ltclstub85
  > C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x24):
  > undefined reference to `RegDeleteKeyEx'
  > C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x4f):
  > undefined reference to `RegDeleteKeyEx'
  > C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0x79):
  > undefined reference to `RegDeleteKeyEx'
  > C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xa3):
  > undefined reference to `RegDeleteKeyEx'
  > C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xcd):
  > undefined reference to `RegDeleteKeyEx'
  > C:\DOCUME~1\Romer\IMPOST~1\Temp\ccYnj5jw.o:uninstal.c:(.text+0xf7): more
  > undefined references to `RegDeleteKeyEx' follow
  > collect2: ld returned 1 exit status
  > make: *** [uninstal.exe] Error 1
  > --------------------

Setting WINVER to 0x0502 on Make_ming.mak works but then it wouldn't
work for pre-Win2k systems.

--
Cesar

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Mon, Aug 2, 2010 at 11:42 AM, Guopeng Wen <wenguopeng@...> wrote:
> I found the 7.3d NSIS installer I built cannot uninstall Vim on
> Windows XP SP3.  When I replicate the uninstallation process
> manually, the following error was reported when launch
> "uninstal.exe":
>
>    Entry Point Not Found:
>    The procedure entry point RegDeleteKeyExA could not be located
>    in the dynamic link library ADVAPI32.DLL.
>
> It turns out RegDeleteKeyEx() is only available on 64 bit Windows,
> according to MSDN:
>    http://msdn.microsoft.com/en-us/library/ms724847(VS.85).aspx
> Minimum supported client:
>    Windows Vista, Windows XP Professional x64 Edition
>
> That function call was introduced in changeset b204ac54bea4:
>    Fix: the MS-Windows uninstaller did not delete registry keys on
>    64 bit systems.
>
> The simple patch (against changeset 7f578da7edb2) I attached defines
> a macro REG_DELETE_KEY, which translates to RegDeleteKeyEx when
> WIN3264 defined, and to RegDeleteKey otherwise.
>
> I only tested the patch on Windows XP SP3, it works.  I do not have
> 64-bit system to verify with, it should work in theory since the
> code is the same after pre-processing when WIN3264 is defined.

I should also mention that I built Vim with MinGW, WINVER was set to
0x0500.  uninstal.c was built fine but the executable won't run on
32-bit Windows XP.  The "RegDeleteKeyExA entry point not found in
ADVAPI32.DLL" error will be reported as mentioned above, and
"uninstal.exe" would abort without doing anything.

Regards!

--
Guopeng

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Christian J. Robinson wrote:

> g++-3 -shared -O2 -mno-cygwin -s -o gvimext.dll \
>                  -Wl,--enable-auto-image-base \
>                  -Wl,--enable-auto-import \
>                  -Wl,--whole-archive \
>                          gvimext.o gvimext.res gvimext_ming.def \
>                  -Wl,--no-whole-archive \
>                          -L/lib/w32api -luuid
> [...]/AppData/Local/Temp/ccISkFaJ.o:uninstal.c:(.text+0x44a): undefined
reference to `_RegDeleteKeyEx'
> [...message repeats...]
> collect2: ld returned 1 exit status
> make: *** [uninstal.exe] Error 1

I have just pushed a workaround.  No idea if this actually works:

# ifndef KEY_WOW64_64KEY
#  define KEY_WOW64_64KEY 0x0100
#  define RegDeleteKeyEx(a, b, c, d) RegDeleteKey(a, b)
# endif


We might actually need a runtime check too.


--
The budget process was invented by an alien race of sadistic beings who
resemble large cats.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- 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    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Dominique Pelle wrote:

> Vim-7.3d (2467:7f578da7edb2) accesses uninitialized memory when
> encrypting an empty buffer with cryptmethod=blowfish:
>
> $ valgrind --num-callers=50 --track-origins=yes --log-file=/tmp/vg.log \
>   vim -u NONE -N -c 'set cm=blowfish' \
>     -c 'call feedkeys(":X\<CR>foo\<CR>foo\<CR>:sav! /tmp/foo\<CR>")'
>
> ... and /tmp/vg.log contains:
>
> ==6126== Use of uninitialised value of size 4
> ==6126==    at 0x805C630: bf_e_block (blowfish.c:340)
> ==6126==    by 0x805CCAB: bf_e_cblock (blowfish.c:385)
> ==6126==    by 0x805D20E: bf_crypt_encode (blowfish.c:611)
> ==6126==    by 0x811AFC9: crypt_encode (misc2.c:3868)
> ==6126==    by 0x80FDFFB: ml_encrypt_data (memline.c:4849)
> ==6126==    by 0x80F6422: mf_write_block (memfile.c:1165)
> ==6126==    by 0x80F632D: mf_write (memfile.c:1121)
> ==6126==    by 0x80F59A4: mf_sync (memfile.c:599)
> ==6126==    by 0x80FA11D: ml_preserve (memline.c:2330)
> ==6126==    by 0x80C8919: buf_write (fileio.c:4160)
> ==6126==    by 0x809832D: do_write (ex_cmds.c:2706)
> ==6126==    by 0x8097DF0: ex_write (ex_cmds.c:2519)
> ==6126==    by 0x80A85C8: do_one_cmd (ex_docmd.c:2656)
> ==6126==    by 0x80A5EA1: do_cmdline (ex_docmd.c:1122)
> ==6126==    by 0x812E54B: nv_colon (normal.c:5319)
> ==6126==    by 0x8127BE7: normal_cmd (normal.c:1190)
> ==6126==    by 0x80E8ECF: main_loop (main.c:1260)
> ==6126==    by 0x80E8904: main (main.c:965)
> ==6126==  Uninitialised value was created by a heap allocation
> ==6126==    at 0x4024F70: malloc (vg_replace_malloc.c:236)
> ==6126==    by 0x8117E4E: lalloc (misc2.c:920)
> ==6126==    by 0x8117D3E: alloc (misc2.c:818)
> ==6126==    by 0x80F4F79: mf_open (memfile.c:133)
> ==6126==    by 0x80F68D7: ml_open (memline.c:311)
> ==6126==    by 0x8053830: open_buffer (buffer.c:93)
> ==6126==    by 0x80EABB0: create_windows (main.c:2597)
> ==6126==    by 0x80E8598: main (main.c:809)
> (and more errors after that)
>
> It happens with 'cm=blowfish' but not with 'cm=zip'.
> I have not found the fix yet.

Strange, how can this code use memory allocated in mf_open()?
Perhaps that's for mf_seed.  Ah yes, for an empty buffer the memfile
doesn't exist, "mfp->mf_fd < 0", and the seed isn't stored.
Thus ml_open_file() lacks a call to ml_set_crypt_key().
Something like that.  Can you find a fix now?

--
Sometimes you can protect millions of dollars in your budget simply by buying
a bag of cookies, dropping it on the budget anylyst's desk, and saying
something deeply personal such as "How was your weekend, big guy?"
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- 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    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Mon, 2 Aug 2010, Bram Moolenaar wrote:

> Christian J. Robinson wrote:
>
>> [...]/AppData/Local/Temp/ccISkFaJ.o:uninstal.c:(.text+0x44a):
>> undefined reference to `_RegDeleteKeyEx'
>
> I have just pushed a workaround.  No idea if this actually works:
>
> # ifndef KEY_WOW64_64KEY
> #  define KEY_WOW64_64KEY 0x0100
> #  define RegDeleteKeyEx(a, b, c, d) RegDeleteKey(a, b)
> # endif

It at least allows compilation without modifying the makefile.
Unfortunately I can't test it because I don't actually use the
installer/uninstaller; I keep the stable 7.2 release installed
"globally" on my Windows system, and I have a locally installed
version for cygwin and just copy the native Windows gvim.exe binary I
also build to the same runtime directory so I can run it as well.

- Christian

--
Christian J. Robinson <heptite@...> -- http://christianrobinson.name/

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Guopeng Wen wrote:

> I found the 7.3d NSIS installer I built cannot uninstall Vim on
> Windows XP SP3.  When I replicate the uninstallation process
> manually, the following error was reported when launch
> "uninstal.exe":
>
>     Entry Point Not Found:
>     The procedure entry point RegDeleteKeyExA could not be located
>     in the dynamic link library ADVAPI32.DLL.
>
> It turns out RegDeleteKeyEx() is only available on 64 bit Windows,
> according to MSDN:
>     http://msdn.microsoft.com/en-us/library/ms724847(VS.85).aspx
> Minimum supported client:
>     Windows Vista, Windows XP Professional x64 Edition
>
> That function call was introduced in changeset b204ac54bea4:
>     Fix: the MS-Windows uninstaller did not delete registry keys on
>     64 bit systems.
>
> The simple patch (against changeset 7f578da7edb2) I attached defines
> a macro REG_DELETE_KEY, which translates to RegDeleteKeyEx when
> WIN3264 defined, and to RegDeleteKey otherwise.
>
> I only tested the patch on Windows XP SP3, it works.  I do not have
> 64-bit system to verify with, it should work in theory since the
> code is the same after pre-processing when WIN3264 is defined.

It does work on my Windows XP system.  Apparently it's hard to predict
if RegDeleteKeyEx() is going to work.  This would require using
LoadLibrary() and GetProcAddress().


--
The fastest way to get an engineer to solve a problem is to declare that the
problem is unsolvable.  No engineer can walk away from an unsolvable problem
until it's solved.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- 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    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php