Koen van de Sande
22nd September 2002 10:43 UTC

VPatch 1.4 beta released
I've finished a new beta version of the patch generator. What's new:
- Made patch generator 15-20% faster
- Removed progress indicator from GUI and replaced it with a console window
- Improved the GUI some more
- Included command line utilities (GenPat.exe and VAppend.exe)

Download VPatch 1.4 beta

It's a beta version because I did not get a chance to do:
- create a DLL version of the runtime for NSIS 2 (can someone give me a hand? I need an ExDLL project which I can open & compile in MS Visual C++ 6.0)
- check that the included PatchLib.NSI can be made any shorter by using new features of NSIS (it works but perhaps it could be shorter)

Let me know if you find any bugs/have problems!

kichik
22nd September 2002 12:11 UTC

What's wrong with the ExDLL that already comes with NSIS? Just edit myFunction and you are set. Make sure you compile in Release mode.

If you still can't compile, what errors do you get?

brainsucker
22nd September 2002 12:39 UTC

ExDLL
I think he gets something like my problem: I can't open these Projects with MSVC++7.0, it say the project file is corrupt. Install Options - the same, and the LangDll opens successfully... Ok, going to find differences... will report...

kichik
22nd September 2002 12:46 UTC

Well...

(can someone give me a hand? I need an ExDLL project which I can open & compile in MS Visual C++ 6.0)

Koen van de Sande
22nd September 2002 12:54 UTC

If I open the ExDLL workspace in MS Visual C++ 6.0, then the workspace window remains empty - nothing is opened. If I open the project then there is a complaint that the project file is "not ok" (don't know the exact message).
The problem is that I don't know how to create such a project file 'from scratch'. I can copy/paste into exdll.c, but I can't 'use' it without a proper project file.

kichik
22nd September 2002 13:06 UTC

I can't help you if you don't give me the exact error message...

To start a project from scratch go to File->New->Projects->Win32 Dynamic-Link Library. Give it a name, and compile. ExDLL has some size optimizations too. It is better to just use ExDLL and change all of the names.

brainsucker
22nd September 2002 13:43 UTC

Solution
The solution was just as simple: someone sent (perhaps while using CVS?) these damaged dsp files with lineends in form of "CR" or "LF" (I never could remember which one means '0x0A' and which '0x0D' :), and by microsoft standarts (it seems so, at last) lineends should be "CRLF" or "LFCR" ( the same problem :).

Convertor attached. Use "ConvertLN < infile > outfile".
Maybe someone could update files at repository? ;)

P.S. Huh, just updated the version, cause previous should damage files with right lineends.

kichik
22nd September 2002 13:50 UTC

That depends on the CVS client you use to download the files. TortoiseCVS converts it to MS format. I will see to it that the night build will also be in MS format.

brainsucker
22nd September 2002 14:09 UTC

:)
Huh... In fact this is interesting microsoft bug... All other files could have any format, and only project ones are so stupid... And why some people could open it and others no?

Kichik and Koen: What OSes and MSVC (with SP numbers) do you have?
(I hope this is not a confedential information... :)

P.S. When the nighlty snapshot occurs, please? (In GMT)

kichik
22nd September 2002 14:15 UTC

Like I said brainsucker, it depends on the CVS client. I am using Tortoise and it converts it to MS line breaks automatically... The nightly snapshot doesn't. Rainwater has the times, I have no idea what the times are :)

Koen van de Sande
22nd September 2002 16:35 UTC

Changing to CRLF does miracles :D
I was using the nightly snapshot btw.

I've converted most of the project, however I'm getting two compile errors now:
1) could be related to me renaming exdll.c->exdll.cpp (it occurs in the DLLmainCRTsomething function, on the hInstance= line):

exdll.cpp
F:\vpatch\Code\rev15\DLL_C\exdll.cpp(93) : error C2440: '=' : cannot
 convert from 'void *' to 'struct HINSTANCE__ *'
        Conversion from 'void*' to pointer to non-'void' requires an explicit cast
Error executing cl.exe.

Linking...
   Creating library Release/vpatchdll.lib and object Release/vpatchdll.exp
exdll.obj : error LNK2001: unresolved external symbol __chkstk
vpatchdll.bin : fatal error LNK1120: 1 unresolved externals

Sunjammer
22nd September 2002 17:04 UTC

Right, KiCHiK was gonna answer you, but then he had to go, so then Eccles was gonna answer you, but then he had to go.... so it fell to me :)

I was going to suggest you just rename it back to .c but then I noticed that you have lots of variable declarations after code which of course the C compiler won't like. Therefore I'd suggest you do what one of my C++ plugins does, move your actual exported plugin methods into a .cpp file and mark the functions like :

extern "C" void __declspec(dllexport) myexportfunc(the usual plugin args)

And include the exdll.h file at the top of the .cpp file like so :

extern "C"
{
#include "exdll.h"
}

That might help. KiCHiK's quick response to this was (a) don't rename the file to .cpp, and (b) he said something about watching those buffer sizes... I think he must have been cautioning against what you yourself in the code have commented on, hoping your 1024 byte buffers don't get overrun.

If this doesn't solve your problem email me at ximon_eighteen@3b2.com and I'll put the effort in to getting your project compiling, right now I'll leave it to you tho in case that info helps.

kichik
22nd September 2002 17:33 UTC

I wasn't talking about his comments, I was talking about his second error, the linking error. __chkstk is a libc function that makes sure there is no stack overflow. It is automatically added to functions that needs more than 4K of memory on the stack. If you declare a buffer the size of 16000, it will be added, but, libc is not used for optimizing porpuses (saves about 50KB...) and thus __chkstk can not be found.
To solve this you either have to dynamically allocate the large buffers, or make them static. Static are "statically allocated" only once in memory and not with every call to the function and thus doesn't need __chkstk.

If you need any further assitance please drop by the IRC channel.

Koen van de Sande
22nd September 2002 19:31 UTC

It compiles now :D
It's just like you all said, thanks.
This just leaves one issue: where to store the patch data?
- Append it to the DLL: the EXE works this way, however I need to get the DLL name then (inside the DLL). Don't know how to do this with my limited API knowledge. And I'm not sure if you can let NSIS look in the current folder for plugins too?
- Keep it in a seperate file: Then it can be easily read from the stack. Just some extra work for the user.
Any suggestions? First one would be nice, but 2nd is easier to implement.

Note: I can't access the IRC server. I have a dynamic IP address, and my current one is banned by some IRC server about 3 months ago. So unless I pull my net connection for an hour and acquire a new IP... you get the idea :rolleyes:. And the chances of getting a new IP succesfully... :igor:

Joost Verburg
22nd September 2002 19:38 UTC

Originally posted by Koen van de Sande
Keep it in a seperate file: Then it can be easily read from the stack. Just some extra work for the user.
Any suggestions? First one would be nice, but 2nd is easier to implement.

Koen van de Sande
22nd September 2002 19:46 UTC

Originally posted by Joost Verburg

I prefer a separate file (also useful if you want to patch multiple files).

Koen van de Sande
23rd September 2002 21:54 UTC

Got to do a little more testing... but I just wrote a new implementation of the patch generator. And if it is working as good as it appears to be... it's fast :D