"Alon Bar-Lev" wrote:
On Thu, Apr 7, 2011 at 3:48 PM, David Sommerseth wrote:
Good idea! I wasn't aware of that one. I'll fix this. I will anyway
choose to fallback to C:\WINDOWS\Temp if %SystemRoot% is not found, even
though I believe this is most likely not something which should happen.
"David Sommerseth" wrote:
- /* Try to use %TEMP% or %TMP% */
- tmpdir = getenv("TEMP");
- if( !tmpdir ) {
-tmpdir = getenv("TMP");
+ CLEAR (tmpdir);
+
+ /* Try to use %TEMP%, %TMP% or %SystemRoot%\Temp */
+ envptr = getenv("TEMP");
+ if( envptr ) {
+return envptr;
}
- if( !tmp
Since MingW for quite a long time (since 3.2 in 2008?) has defined
'uint32_t' etc. in it's , we need to guard against defining
them again. Ideally we should figure out in what version of MingW
this happened. But for now:
--- SVN-Latest\config-win32.h Sat Apr 09 05:59:09 2011
+++ config-win32.h
Sorry for the noise. I just discovered you've switchd to Git since I was
involved
with OpenVPN. With the SVN-repo still there, I wrongfully assumed that was the
trunk (latest top) of developement. Here is an updated patch:
--- Git-latest\win\config.h.in Sat Apr 09 14:25:58 2011
+++ win\config.h
"Heiko Hund" wrote:
+#ifndef IN6_ARE_ADDR_EQUAL
+#define IN6_ARE_ADDR_EQUAL(a,b) \
+__const uint32_t *) (a))[0] == ((__const uint32_t *) (b))[0]) \
+ && (((__const uint32_t *) (a))[1] == ((__const uint32_t *) (b))[1]) \
+ && (((__const uint32_t *) (a))[2] == ((__const uint32_t *) (b))
"Alon Bar-Lev" wrote:
These macros are s ugly!
I tend to agree; had to read the code closely. But this hack was cool:
union {
FUNC ## _fn *type;
FARPROC *ptr;
} u = { .type = &(LIB ## _ ## FUNC) };
...
*(u.ptr) = GetProcAddress (lib, (#FUNC));
Where did you get that Heiko?
"Alon Bar-Lev" wrote:
Why not:
#ifdef WIN32
#define access _access
#endif
We should write "#ifndef _MSC_VER". MingW's access() handles
X_OK correctly. From MingW's :
#ifdef __USE_MINGW_ACCESS
/* Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, re
"Tiran Kaskas" wrote:
Already done the ssl part, only polarssl. It is working perfect and does
support 16bit with no change.
You got all the data in PolarSSL, LZO and OpenVPN to fit in a 16-bit
data-segment of 64 kByte? I'll be amazed. What memory model would
be needed to link in all the cod
Simon Rozman wrote:
However, I did stare-review your code:
- It does not introduce any new Windows API calls it has not used before.
- It compiles fine.
It also builds fine here with cl v19.11.
But using clang-cl v5, I'm getting:
In file included from src/openvpn/argv.c:36:
./src/openvpn/sy
While compiling src/openvpn/options.c with MSVC 2015, I got this
error:
src/openvpn/options.c(5944): fatal error C1026: parser stack overflow,
program too complex
I've also seen such error in GeoIP-lib due to all the 'if..else if' statements.
Can this be written using some kind of a table-looku
Gert Doering wrote:
> For the time being we just use a compiler that is not mainly a pain in the
> back, solidly stuck in the last century before C99 - as in, none of the
> core developers compile on windows, we all do cross-compilation with
> mingw64 on Linux.
Well, MSVC 2015 is pretty up-to-da
Fish Wang wrote:
> I'm finishing up a patch to make sure OpenVPN compiles under Visual Studio.
> I have several questions;
I'm also compiling using TDM-MinGW and MSVC-2015. But since approx 2 years,
the CL compiler breaks at compiling options.c:
src/openvpn/options.c(7937): fatal error C1026: p
Just as an experiment, I compiled openvpn.exe using MinGW w/o
'ENABLE_CRYPTO' defined. Duh, you think. What would be the benefit of
that? I ask myself the same. This code (at line 4079):
#else /* ifdef ENABLE_CRYPTO */
fprintf(fp, usage_message,
title_string,
o.ce.conn
Gert Doering wrote:
>> uses a 'title_string[]' as format with no parameters specified and
>> thus crashes as expected. So is all code outside '!defined(ENABLE_CRYPTO)'
>> really dead code or what?
>
> Actually, "usage_message" is the format string here...
Ah, my bad. Then it's a simple fix:
-
Arne Schwabe wrote:
>> Did you manage to work around that?
>>
>> I'm using the latest CL v.19.00.24215.1. I also reported this 2 years ago
>> in:
>> https://sourceforge.net/p/openvpn/mailman/message/34683175/
>>
>
> I managed to work around that. By adding a done=true;variable and then
> spli
"James Yonan" said:
> Pthreads doesn't work on Windows. Windows has its own threading model and is
> incompatible with pthreads.
Not so. There is pthread-win32 at
http://sources.redhat.com/pthreads-win32/
I've successfully used it in libpcap etc. But OpenVPN uses native
Windows calls, so using
What's the situation with the Sourgeforge CVS server?
Seems the OpenVPN-2.0 beta 2 isn't in CVS (in tar-ball
only).
I used these commands to checkout
cvs -z3 -d:pserver:anonym...@cvs.sourceforge.net:/cvsroot/openvpn login
cvs -z3 -d:pserver:anonym...@cvs.sourceforge.net:/cvsroot/openvpn co op
The latest MingW runtime and headers defines 'ssize_t'.
So this patch is needed:
--- openvpn-2.0_beta2/config-win32.h.in Thu May 13 23:56:23 2004
+++ config-win32.h.in Wed May 19 16:54:07 2004
@@ -42,8 +42,12 @@
#define random rand
#define srandom srand
-typedef unsigned int in_addr_t;
+typed
"James Yonan" said:
> This release has some cool new stuff, most notably TCP support in server
> mode.
> While all OSes which OpenVPN supports should be able to run as a multi-client
Changelog from CVS a few minutes ago have this:
$Id: ChangeLog,v 1.89.2.35 2004/06/30 00:35:40 jimyonan Exp
I tried building latest beta16 with gcc 3.4.1 and MingW and
struck what I suspect is a gcc bug. While linking I got:
tun.o(.stab+0x11024): In function `ipset2ascii_all':
G:/MingW32/src/inet/OpenVPN/tun.c:3321: undefined reference to `get_netsh_id'
tun.o(.stab+0x110b4):G:/MingW32/src/inet/OpenVPN/
Simply running "openvpn -h" causes a SIGSEGV. I was hoping '-h' would
print the help, but obviously not. Happens with '-v' too.
Attached is the Dr. MingW crash dump. No config-file was present, btw.
--gv
openvpn.exe caused an Access Violation at location 00401688 in module
openvpn.exe Reading
It looked rather suspicious to want (S_IRUSR | S_IWUSR) for MingW
when opening files in status.c. Patch:
--- status.c.orig Wed Dec 08 00:52:04 2004
+++ status.cMon Dec 13 14:44:17 2004
@@ -77,7 +77,7 @@
{
switch (so->flags)
{
-#ifdef _MSC_VER
+#ifdef WIN32
Using '\' in #include<> messes up the dependency generation (gcc -MM ..).
Or at least MingW's make doesn't like it. So could you please use Unix slashes.
--- CVS-latest\cryptoapi.c Sun Nov 28 18:22:01 2004
+++ cryptoapi.c Sun Jan 23 09:31:06 2005
@@ -32,8 +32,8 @@
#include
#include
#includ
MingW (ver 3.7) doesn't have the "ieproxy.h" header. But it doesn't seem to
require it either since most types and prototypes are in .
I patched proxy.c to make it build:
--- CVS-latest\proxy.c Mon Dec 12 18:00:00 2005
+++ proxy.c Mon Feb 20 18:05:32 2006
@@ -39,7 +39,7 @@
#include "base64.h
Simon Rozman wrote:
I have almost finished integrating tapctl.exe and openvpnmsica.dll utilities
for MSI packaging into the OpenVPN/openvpn repo. However, I am totally new
with MinGW and would need some help.
How do you tell the OpenVPN's build process to create a DLL file, not an
EXE?
Usuall
I noticed the .rc-files for programs uses
'FILETYPE 0x2L'. The 0x2L' is for a .DLL (VFT_DLL).
Ref: Win-Kit's 'um/verrsrc.h':
#define VFT_DLL 0x0002L
Hence these '0x2L' should be replaced with 'VFT_APP':
--- a/src/openvpn/openvpn_win32_resources.rc 2016-11-06 10:54:00
+++ b/src/openvpn/ope
26 matches
Mail list logo
