Have some improvements on Windows: CRT
Mihai Nita
the redistributable for VS 2008.
I have come up with a way to build my jni library (doing coloring,
Unicode output) using msvcr.dll, which is part of the normal system.
I would like top help doing it for jansi.dll, the code of the dll does
not seem to be part of the source tree.
Thank you,
Mihai
Hiram Chirino
Sound like a good idea. The source code to the native library is
built using: https://github.com/fusesource/jansi-native
Regards,
Hiram
FuseSource
Web: http://fusesource.com/
Mihai Nita
I have two ways to handle this. Both of them need to link with /
NODEFAULTLIB, and both need some extras (for the entry points, and the
CRT proper)
Option 1: using the WDK
Basically the solution described here:
http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/
So one would have to download the WDK (http://www.microsoft.com/
download/en/details.aspx?displaylang=en&id=11800), mount the ISO, and
extract
msvcrt.lib and msvcrt_win2003.obj (from libs_x86fre_cab001.cab and
libs_x64fre_cab001.cab, for 32/64 bits)
And the two files should be added as input to the linker to (to
quiet the errors from /NODEFAULTLIB)
Option 2: my own "hack"
I have generated a msvcrt.lib directly from msvcrt.dll, and I have
wrote my ow minimal entry point (_DllMainCRTStartup)
The "official" _DllMainCRTStartup is way more complicated (and has
more dependencies), but most of it is not needed
if the thing is small, and plain C (so no exceptions and other
fancy C++ stuff)
The last missing part is to quiet the complains about
security_check_cookie. So you either link with RunTmChk.lib (part of
VS libs), or disable the security checks.
Each has pros and cons.
Option 1 uses official MS files, but require the WDK (I doubt that one
can legally extract and store in github the 4 lib/obj needed)
Option 2 is a totally unsanctioned hack. (ok, 1 is also a hack, but
less hackish :-)
Which one would you prefer?
I can send you a batch file building the 32 bit dll (for now) with
both options (I did not change the VS project files yet).
And/or I can send you the results of the bilds (the DLLs), so that you
can test a bit.
Depending on your choice I can start updating the VS projects
(although I only have VS2010 now)
Cheers,
Mihai
Hiram Chirino
Regards,
Hiram
FuseSource
Web: http://fusesource.com/
Mihai Nita
Tell me when you got it, and I will delete it.
Contains:
1. updated src files
- the changes documented in another post to enable isatty
- few changes to kill some warnings (define isatty and getch, two
casts to PINPUT_RECORD)
2. crt_my folder
- my mini-entry point (crtdll.c)
- msvcrt.lib for Win32 and x64, generated from the Win7
msvcrt.dll
(dumpbin.exe /exports msvcrt.dll, created a msvcrt.def from the
result, then lib /def:msvcrt.def /out:msvcrt.lib)
3. updated vs2010.vcxproj (vs2010WinCRT.vcxproj)
- added releaseWinCRT configuration, based on release
- added crt_my/crtdll.c, but disabled it in release and debug,
only enabled it in releaseWinCRT
- Linker - General: added crt_my/$(Platform) as Additional
Library Directory
- Linker - Input: Ignore All Default Libraries (/NODEFAULTLIB)
- Linker - Input: removed
user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;odbccp32.lib,
and added msvcrt.lib;RunTmChk.lib instead
4. the target folder with the .dlls built by me
I did not have time to test the result of this (it's 3 am :-)
But I did test earlier the dlls built with a batch file (so not
thru .vcxproj), and only 32 bits.
That worked ok, but I can't be sure I did not miss something in
the .vcxproj
Would be great if you have some kind of test suite :-)
Mihai
Hiram Chirino
generated by the following module:
https://github.com/fusesource/jansi-native
I've taken your changes and applied them to the latest copy of that
project. I'm going to attach a patch with the modifications. You can
apply the patch using "git apply" to a clone of the project. I did a
quick build on a win64 system and it seemed to work fine. You just
have to run "mvn install" on the project from the a Windows SDK CMD
prompt. That will generate the native build project and build it.
The patch still needs a little more work though. All the new text
files need a License header so folks know that your contribution is
also ASL 2.0 licensed.
Also could you add a readme.txt to the windows directory or update the
root readme with info of how .lib files were created.
Also I'd rather receive your contribution via a github fork [1] and
then a pull request [2]. That way the commit history clearly tracks
that you were the originator of the change.
Regards,
Hiram
FuseSource
Web: http://fusesource.com/
[1]: http://help.github.com/fork-a-repo/
[1]: http://help.github.com/send-pull-requests/
Mihai Nita
First, thanks for taking this, I am happy if you like it :-)
Unfortunately, I am pretty new to the Java/maven world (coming from C/C
++)
And I am still confused by the whole maven generated .c and VC project
files :-)
I don't know (for instance) where should I look for the original files
(that are used by Maven to generate the stuff)
For instance, what to change so that maven generates the right
jansi.h?
In general (no jansi related, but as a programmer) I find that I don't
really like maven.
There is to much "magic" happening under the hood
(for instance I used maven on 2-3 other project, and discovered I
ended up with 1.4 GB and 7000 files downloaded by maven)
So I don't think it helps with dependencies management mess, but in a
way makes it worse
(by hiding it, people don't learn about it, and are not compelled to
clean it)
Ok, enough with the rant :-)
Back to jansi :-)
I will also have to take a look at git. I did play a bit with it a
while ago, but not much.
So I don't even have a github account (and I did not intend to create
one :-)
I'll see how fast I can get up to speed.
My intention was not to become a full time contributor, but more like
"bug report/feature request" with a proposed fix attached :-)
You are the project owner, take only what you like, throw away the
rest :-)
So I don't care about credits or anything.
Everything I do for jansi is yours, put it under whatever license you
want.
To summarize:
- I will create a github account and learn more about git
- if you help me with some pointers with the maven code generation, I
will try to make the changes in the right place
But meantime, to keep things going faster, can I still send you small
one-off changes as I did?
I know it is more work for you, but I also don't have much time for
research (I go to bed after 3am as it is :-)
So it might be a while before I get up to speed, and I would hate to
wait so long for jansi 1.8 :-)
Best regards,
Mihai
Mihai Nita
> have to run "mvn install" on the project from the a Windows SDK CMD
> prompt. That will generate the native build project and build it.
No so easy :-)
I only have VS2010 installed, and mvn install fails, because there is
no vcbuild anymore.
And I don't know where to change it.
(one example of why I don't like maven: hidden stuff that magically
works, until it doesn't :-)
Mihai
Hiram Chirino
>
> First, thanks for taking this, I am happy if you like it :-)
>
> Unfortunately, I am pretty new to the Java/maven world (coming from C/C
> ++)
> And I am still confused by the whole maven generated .c and VC project
> files :-)
> I don't know (for instance) where should I look for the original files
> (that are used by Maven to generate the stuff)
> For instance, what to change so that maven generates the right
> jansi.h?
So in maven by convention, everything in src are source files, and the builds
generate files under target. In this project we are using a
hawtjni-maven plugin
to code generate the native source project. This build will create the c source
distro for the shared lib:
target/jansi-native-${version}-native-src.zip
Then it extracts it (to target/native-build) and builds the shared lib and
package it into:
target/jansi-native-${version}-${platform}.jar
Now lets backup and explain how the source generation happens.
HawtJNI examines the annotations on the java class files to control how
the c or c++ JNI glue code is implement to call the native functions.
The java files under src/main/java is what gets scanned for
code generation purposes. And the c/c++ code is initially generated to
target/generated-sources/hawtjni/native-src
The following generated files change depending on how you
define your java classes and annotations:
jansi.c
jansi_stats.c
jansi_stats.h
jansi_structs.c
jansi_structs.h
And these files are always the same no matter what.
hawtjni.c
hawtjni.h
windows/stdint.h
The next step then creates a native source distribution packaging
all the files in src/main/native-package, adding in the generated
c/c++ files under the package src dir and then adding/generating
standard distribution files if they are missing. The GNU auto tools
based build files get generated if missing, the VS project files
also get generated if missing. The results of this package generation
step are stored at target/generated-sources/hawtjni/native-package
And that's about it. That's why I added your files/changes under the
src/main/native-package directory, that way the would just get included
in the file native source distro.
> In general (no jansi related, but as a programmer) I find that I don't
> really like maven.
> There is to much "magic" happening under the hood
> (for instance I used maven on 2-3 other project, and discovered I
> ended up with 1.4 GB and 7000 files downloaded by maven)
> So I don't think it helps with dependencies management mess, but in a
> way makes it worse
> (by hiding it, people don't learn about it, and are not compelled to
> clean it)
I totally understand. Most of all those dependencies are being used
by the build tools
plugins. They all tend to use slightly different versions of common
dependencies
so you end up downloading the internet. The bright side is that you
can run any
build plugin in maven without worrying if another plugin in the build
has a conflicting
dependency. Each runs plugin runs against the dependency versions which it was
developed/tested against so you end up with very reliable builds even
when you start
mixing large numbers of plugins.
And I'm the kinda guy who like build tools that keep working even if you add in
more features plugins over time. I'm willing to pay the bandwidth/disk costs as
long as things just work.
> Ok, enough with the rant :-)
> Back to jansi :-)
>
yeah me too!
> I will also have to take a look at git. I did play a bit with it a
> while ago, but not much.
> So I don't even have a github account (and I did not intend to create
> one :-)
> I'll see how fast I can get up to speed.
>
It's not too hard. I highly recommend you give it another shot. I's a
lovely SCM.
> My intention was not to become a full time contributor, but more like
> "bug report/feature request" with a proposed fix attached :-)
> You are the project owner, take only what you like, throw away the
> rest :-)
>
> So I don't care about credits or anything.
> Everything I do for jansi is yours, put it under whatever license you
> want.
Thanks. But you've made some great contributions and once you get
setup I would not mind
letting you do direct commits to the project. I like to give talented
folks like
you easy access to encourage future contributions!
Mihai Nita
Request (would be the smart thing to do),
but I am not sure. So I am also using this tell you: I did a fork,
integrated all, and submitted a Pull Request.
But I guess you have a job, and a family, and a life, so please don't
interpret this as me putting pressure :-)
i only want to make sure you know about it.
Now, if I get to do some more work on this, it might be nice to make
things as smooth as possible.
So here are some questions (in no particular order):
- Can I bug you (as rarely as I can) with requests for help?
- I can build jansi and jansi-native. but is there a nice, automated
way to generate the final .jar (as found on your web site)?
- I have tried to learn about hawtjni, but can't find a way to
generate:
rc = (jint)(isatty(arg0) ? 1 : 0);
instead of
rc = (jint)isatty(arg0);
- Any way to (still) generate the VS project file, instead of dumping
it there "as is"
And are we dropping the VS2008 support?
- I can add a VS custom step to generate msvcrt.exp and msvcrt.lib
from msvcrt.def
Would save us from storing about 750K of binary data that is in fact
generated from the 45K text msvcrt.def files anyway.
So in a way is in the same class with the .obj files, that are throw-
away
- Should we continue the hand-holding thru this thread/discution
group, should I start a new one (with a better title),
or move it to private emails?
- Please let me know if anything in my submissions is not quite what
it should be
Thanks, and have a nice week-end,
Mihai