[Edbrowse-dev] Windows MSVC140 build

[Edbrowse-dev] Windows MSVC140 build

[Geoff McLane]

Hi all,

This is all about building edbrowse in
Windows 10, in 32 and 64-bits...

Some time back I retired my trusty MSVC10 (2010),
downloaded MSVC14 (2015), and started to re-do
each project... first in 32-bits...

Unfortunately with edbrowse ran into a horrible
warning, that I can not seem able to solve -

  main.c
c:\program files (x86)\microsoft 
sdks\windows\v7.0a\include\sal_supp.h(57): warning C4005: '__useHeader': 
macro redefinition [F:\Projects\edbrowse-geoff\build\edbrowse.vcxproj]
   C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\include\sal.h(2866): note: see previous definition of '__useHeader'
c:\program files (x86)\microsoft 
sdks\windows\v7.0a\include\specstrings_supp.h(77): warning C4005: 
'__on_failure': macro redefinition 
[F:\Projects\edbrowse-geoff\build\edbrowse.vcxproj]
   C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\include\sal.h(2876): note: see previous definition of '__on_failure'

This is a horrific warning, since as you can see it
seems to be in 'system' header files - the MSVC14 include
sal.h is incompatible with the microsoft sdks header
sal_supp.h and specstrings_supp.h... bah!

For now I have suppressed this warning 4005... but would
always strive to avoid that suppression... I have googled
around, and found it reported here and there, but none
provided a solution yet...

Does anyone have any ideas?

There are still some dozen other msvc140 warnings... which
I have left for now...

But the main thing is I had to provide a few small fixes
for some 'errors' that msvc140 exposed...

At the moment I have only done fixes in my
edbrowse-fork, while I test them further... and maybe
refine them before finally adding them to edbrowse...

The two main ones are in jseng-moz.cpp... in the function
readFromEb()

1. Why is 'ssize_t rc;' used, instead of just 'int rc;'?
Unfortunately `ssize_t` does not exist in WIN32. Alternatively
could provide a define or typedef... but why not an 'int'?
Maybe missing something here...

2. Why is '(short unsigned int *)uc_run' used instead
of '(const jschar *)uc_run'? Which seems to be what
the prototype of JS_EvaluateUCScript in jsapi.h...
Again, am I missing something?

The other important item is to define HAVE_STRUCT_TIMESPEC.
For now I have just defined it in eb.h, but this could
perhaps also be done in CMakeLists.txt...

As stated, I will continue to test, and refine, but
look forward to any further comments meantime...

For the 64-bit build I need to also re-do and
install libraries like mozjs-24.lib, and maybe others,
in 64-bit msvc140 form... quite a pain... but will
get there...

Are there any others out there who do a Windows
MSVC build?

Current full patch below...

Regards, Geoff.

<msvc140-32.diff>
diff --git a/CMakeLists.txt b/CMakeLists.txt
index df70164..16b0f16 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -36,7 +36,8 @@ if(WIN32)
          # C4101: 'idx' : unreferenced local variable
          # C4018: '>' : signed/unsigned mismatch
          # C4800: 'JSBool' : forcing value to bool
-        foreach(warning 4244 4101 4090 4018 4800)
+        # C4005: '__useHeader': macro redefinition
+        foreach(warning 4244 4101 4090 4018 4800 4005)
              set(WARNING_FLAGS "${WARNING_FLAGS} /wd${warning}")
          endforeach()
          set( MSVC_FLAGS "-DNOMINMAX -D_USE_MATH_DEFINES 
-D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_WARNINGS 
-D__CRT_NONSTDC_NO_WARNINGS" )
diff --git a/build/build-me.bat b/build/build-me.bat
index e5cc744..386f6a7 100644
--- a/build/build-me.bat
+++ b/build/build-me.bat
@@ -12,6 +12,12 @@
  @set TMPINS=..\..\software
  @set TMPCM=%TMPSRC%\CMakeLists.txt
  @set DOPAUSE=pause
+@set VCVERS=14
+@set GENERATOR=Visual Studio %VCVERS%
+
+pushd %TMPSRC%
+@set TMPSRC=%CD%
+popd

  @call chkmsvc %TMPPRJ%

@@ -22,7 +28,7 @@
  @if NOT EXIST %TMPCM% goto NOCM

  @set TMPLOG=bldlog-1.txt
-@set TMPOPTS=-DCMAKE_INSTALL_PREFIX=%TMPINS%
+@set TMPOPTS=-G "%GENERATOR%" -DCMAKE_INSTALL_PREFIX=%TMPINS%

  @REM 20151031 - Add OSBC support in WIN32 build
  @set TMPOPTS=%TMPOPTS% -DBUILD_EDBR_ODBC:BOOL=ON
@@ -34,7 +40,7 @@
  @goto RPT
  :GOTCMD

-@echo Build %DATE% %TIME% > %TMPLOG%
+@echo Build %DATE% %TIME% in %CD% > %TMPLOG%
  @echo Build source %TMPSRC%... all output to build log %TMPLOG%
  @echo Build source %TMPSRC%... all output to build log %TMPLOG% >> 
%TMPLOG%

diff --git a/src/eb.h b/src/eb.h
index 8cdc3e7..78ec2f2 100644
--- a/src/eb.h
+++ b/src/eb.h
@@ -25,6 +25,12 @@
  #define _GNU_SOURCE
  #endif

+#ifndef HAVE_STRUCT_TIMESPEC
+#if defined(_MSC_VER) && (_MSC_VER >= 1900)
+#define HAVE_STRUCT_TIMESPEC
+#endif
+#endif // HAVE_STRUCT_TIMESPEC
+
  /* seems like everybody needs these header files */
  #include <sys/types.h>
  #include <ctype.h>
diff --git a/src/jseng-moz.cpp b/src/jseng-moz.cpp
index bd276f5..5c411a3 100644
--- a/src/jseng-moz.cpp
+++ b/src/jseng-moz.cpp
@@ -194,7 +194,7 @@ int js_main(int argc, char **argv)

  static void readFromEb(void *data_p, int n)
  {
-    ssize_t rc;
+    int rc;
      unsigned char *bytes_p = (unsigned char *)data_p;
      if (n == 0)
          return;
@@ -2478,7 +2478,7 @@ static void processMessage(void)
          head.n = 0;
          head.proplength = 0;
          if (JS_EvaluateUCScript
-            (jcx, parent, (short unsigned int *)uc_run, uc_len / 2,
+            (jcx, parent, (const jschar *)uc_run, uc_len / 2,
               "foo", head.lineno, v.address())) {
              if (v != JSVAL_VOID) {
                  s = 0;
</msvc140-32.diff>

[Edbrowse-dev] Windows MSVC140 build

[Karl Dahlke]

> The two main ones are in jseng-moz.cpp... in the function

> 1. Why is 'ssize_t rc;' used, instead of just 'int rc;'?

Because the manual page for read() says it returns type size_t.
Implicitly casting that into an int, as in int rc, is no trouble so make that change if you wish.
We're not going to be reading more than 2 gig at a shot.

> 2. Why is '(short unsigned int *)uc_run' used instead
> of '(const jschar *)uc_run'?

don't know - I went for the actual type, but that's platform specific,
so go ahead and use jschar * instead, it works.


Karl Dahlke

Re: [Edbrowse-dev] Windows MSVC140 build

[Geoff McLane]

Hi Karle,

Thanks for the quick reply...

1. Ok, 'size_t' would also be ok, I think... just not 'ssize_t', which 
is not defined...

2. Yes, it seems msvc140 wants a prototype spade cast as a spade, not a 
'short ... *', like it may in fact be ;=))

Just brought my fork 100% up to current repo, and find some other errors.

3 unresolved -  ftruncate, truncate, and usleep, so need to look at 
these tomorrow, or soonest...

Meantime have pushed my current changes to a 'msvc140-32' branch in my 
fork...

Be back soon...

Regards, Geoff.

[Edbrowse-dev] Windows MSVC140 build

[Karl Dahlke]

Yes Chris and I are setting up caching, as all other browsers do, and that has brought in a few new unix calls.
Instead of usleep(5000) you can use Sleep(5).
truncate() changes the length of the file; I hope windows has some equivalent.

Karl Dahlke

Re: [Edbrowse-dev] Windows MSVC140 build

[Geoff McLane]

Hi karl,

Fully agree with caching... it works very well in windows...

Pushed a quick fix to -
https://github.com/geoffmcl/edbrowse/tree/msvc140-32

But not sure I understood the use of 'ftruncate' in the
second case... but the windows equivalent seems to be
_chsize(fd,0)... but in the 2nd case chose 'unlink(cacheFile)'...

You have closed it, why not remove it? But maybe I miss
something...

And sure, I guess, think, Sleep(5); // ms is the same as
usleep(5000); // microseconds...

Regards, Geoff.

[Edbrowse-dev] Windows MSVC140 build

[Karl Dahlke]

> Pushed a quick fix to -
> https://github.com/geoffmcl/edbrowse/tree/msvc140-32

Ok, not sure how to access or apply this.
I think you still have permissions on our branch, so you can go ahead and push your changes, they seem fine to me.

> not sure I understood the use of 'ftruncate' in the second case...

It should have been cacheControl, a bug, I have fixed it now.
This code only compiles, has not been tested at all.
Chris still has to write the part that connects it to the http engine.
So for now it's just there.
That's ok, you can make sure it builds on windows.
We'll need to test it eventually,
in windows I put the cache directory down in the user specific temp area, where the edbrowse temp directory is.
Unix is of course a different philosophy:  ~/.ebcache
Hopefully I did that part right.
We'll let you know when we have something for you to test.


Karl Dahlke

Re: [Edbrowse-dev] Windows MSVC140 build

[Geoff McLane]

Yes, I think I still have push access to your repo,
but over recent years have got into the habit of
changing, testing only in a forked branch...

And then when I am happy with the results, present
a Pull Request, which I then complete if I also have
access to the upstream master, like in this case...

It is just a few more git steps... so will do this when
tested...

 >> not sure I understood the use of 'ftruncate' in the second case...
 > It should have been cacheControl, a bug, I have fixed it now.

Ok, understand you are just developing the cache code,
and at this stage my changes were only to get a WIN32
msvc140 error free compile...

So I will continue in this just-fix-to-compile mode until you
actually 'connect' to the cache.c code, and want the
results tested, and working in windows...

And yes, I did carefully check where you are putting this in
Windows, and noted that you have used the TEMP environment
variable to locate this, and that is fine and correct in Windows...

And understand the unix philosophy of using ~/.ebcache is
quite different...

So this seems all correct to me, and thanks for taking the effort
to get it right for windows...

Regards, Geoff.