This is geared mainly towards Spasi and people who understand bindings to a backend perspective, but how feasible would it be to create bindings to have Window Handles and stuff. Say someone were to want to edit the actual window and not have the default window.
I know its a really big library, but there is also other things that go into it as we see in LWJGL2 Display and LWJGL3 GLFW. That is Frame Buffer and Pixel Format.
Unfortunately I don’t think LWJGL will be able to offer what you want, as it using GLFW for windowing, and AFAIK, GLFW does not expose those parts of the API.
However, there are very few things that you would need access to window handles for. So what exactly are you trying to do?
Fortunately, LWJGL already exposes a lot of the Win32 API, including PixelFormat and CreateWindow(Ex). See the package org.lwjgl.system.windows.
You can perfectly well create a window and/or an OpenGL context without GLFW just by using the pure Win32 API exposed by LWJGL 3.
In fact, this is what the lwjgl3-swt project does, in order to bring OpenGL >= 3.2 to SWT. See the PlatformWin32GLCanvas class.
Also, GLFW exposes the native window handle which LWJGL 3 provides bindings for.
However, I am not sure whether adding anything/everything of Win32, which is not directly necessary to support Window and OpenGL context creation (such as shaping a window to make it look like a circle), is in the scope of LWJGL.
You could also check out the JNA Platform library - https://github.com/java-native-access/jna/blob/master/www/PlatformLibrary.md It has lots of bindings to Win32 functions around windows and much more (caveat - never used it, although use JNA a lot)
Thanks guys. I wasn’t necessarily talking about adding Win32 API completely to LWJGL.
One of the biggest let downs to using Java is the AWT/JFrame portions.
For a feasibility, though, would porting Win32 to java as a library be a good idea?
I would say no.
Also why would you want to? If you don’t like AWT/Swing, there are plenty of alternatives available - from SWT to GLFW to NEWT.
What would be the benefit of porting (? you mean binding, don’t you?) Win32 to java?
What exactly is wrong with the AWT stuff? And of those wrong things, what bits aren’t solved by LWJGL/JogAmp or SWT?
Cas 
[quote]You could also check out the JNA Platform library
[/quote]
Umm yeah. I tried it, it works great, but after extensive native learning this past since I last posted (holy crap) I am going to stay with the lowest level here JNI. JNA is a really big package and uses reflect package in like every single call to Native.loadLibrary. I don’t want to modify their code for myself. Their conventions hurt my eyes. I also saw a topic in LWJGL github that promoted JNI over JNA and from testing, now I see why.
[quote]I would say no.
[/quote]
[quote]Also why would you want to?
[/quote]
I’ve learned that it is a very huge library, but I think its worth exposing it to a point to where you can modify the entire window. I’m asking feasibility because I wanted to be aware of constraints.
[quote]What would be the benefit of porting?
[/quote]
Sorry, by porting I mean binding to allow use of the gdi and win32 libraries.
[quote]What exactly is wrong with the AWT stuff?
[/quote]
Definitely the ability to manipulate the window’s composition outside of width and height. Window elements are a different story and not a concern for me. I’d like my window in a circle And I’m not familiar with NEWT or SWT. Care to shed some light?
I have major respect to whoever makes Natives.
[quote]Hydroque has respect?
[/quote]
just write down some basic JNI code and throw in a [icode]#include <windows.h>[/icode], use win32 api (https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=vs.85).aspx), expose whatever you want.
but what is it what you want ?
Well I already prototyped it after a long ass time of learning JNI. Very specific rulings, a lot of hidden api by Code::Blocks (cluttered), and after going through hell and back with exports I realized I didn’t know C++ as good as I did. Their “new project” option gives me imports and I had to learn the UI and bleh everything set that I needed to reset.
I never really even touched any libraries, so I had to learn linking, exporting to DLLs, the window api itself. I am still shakey on using pointer logic. I’m pleeding mercy for a lot of the functions to have prefixes at least. Loading windows.h? Here have these functions in your scope… make sure none of them override.
I want to thank you for that link, though. I was searching for a comprehensive list of things. I couldn’t tell you how many ‘tutorials’ it took to actually explain everything till I could use GetModuleHandle(NULL). Nonetheless… what I actually want is something like this…
This thread was started by a moderator CodeAssassin who wrote a tutorial and gave source files in a rar at this url. So I deleted the exe out of it and did a fresh compile. They had a cool image in there that said “Apocalipse Trojan”. It has no close button or anything so alt-f4 might work or end process Example.exe
tldr; skinning windows
You can already do irregularly shaped windows in AWT.
Cas
Yeah, let’s just reinvent the wheel for spurious performance reasons that you haven’t quite understood! 
And as @princec says, what you’re currently looking to do might be possible without native code at all.
Why not use C#? It will have much better access to the APIs you want and syntax-wise is practically Java anyway.
write once run anywhere . write once run anywhere . write once run anywhere .
If you’re binding to win32 then you’ve already thrown out cross-platform.
[quote]You can already do irregularly shaped windows in AWT.
[/quote]
Google>[icode]setShape(new Ellipse2D.Double(0,0,getWidth(),getHeight()));[/icode]
Of course…
[quote]Yeah, let’s just reinvent the wheel for spurious performance reasons that you haven’t quite understood! Tongue And as @princec says, what you’re currently looking to do might be possible without native code at all.
[/quote]
It seems like you expect me to actually create the project in a major degree.
What I am doing currently is just playing around with JNI. Having a problem with that is what you should point out. But ‘for spurious performance reasons’ sounds like me alright.
Besides that, JNA extends JNI just to have neat little interfaces which implement your native code the same way. And does it extensively from what I read in the sources. Correct me if I am wrong, but either httpdigest or Spasi concluded that JNA uses JNI at its very core and the overhead is a bit much for the scope of LWJGL in a github problem. Does Hydroque like overhead or the core? Core. I will learn JNI and practice it. To be honest, IMO JNI is much nicer to use.
[quote]Why not use C#? It will have much better access to the APIs you want and syntax-wise is practically Java anyway.
[/quote]
With all do respect to C#, its a great language and all, but I wouldn’t be using Java if I wanted to have namespaces, functions in my scope not selectively statically imported, etc. A bunch of mess on top of mess, really. I like clean code. Using Java and JNI, I can write in Java and, when necessary, do things in C/++. I am learning JNI here. It is good to note that I like a bunch of languages, #include <C/++/#>. I wish they would all mesh together into a neat language with modern uses. By modern I mean my subjectivity promoting my wants. Yes, that means more Lua-based things.
[quote]If you’re binding to win32 then you’ve already thrown out cross-platform.
[/quote]
Cross platform is not thrown out entirely. Natives can be swapped out anytime, preferably on run. The java code is still write once run anywhere, but the natives change. I believe that may be some goal of code with multiple natives supporting multiple systems. While having all the core that you need in Java, natives add on the things it can’t do or isn’t implemented in the JRE/JDK. So I think of it as an extension… I think most would consider LWJGL cross platform. In the scope of only binding to win32, yes it throws out cross platform. That isn’t a problem here because I am only here to learn about JNI and what I can do with it. Bindings to win32, gdi32 are a cool little thing I am toying with. I guess bringing out the idea that I’d like dynamic windows is a bit out of scope.
I meant your argument was spurious …
Of course JNA uses JNI - it’s basically a JNI wrapper to libffi, which means you can write your native binding in Java and don’t have to cross-compile. There’s an overhead to it, but in general it’s not a major issue. I’m the writer / maintainer of two JNA-based libraries that are used in Praxis LIVE, but also by a variety of other people. Both of those have real-time constraints. JNA isn’t the bottleneck! The extra overhead in JNA is in the native call itself, not what that call does. JNI isn’t cheap anyway - roll on Panama. IMO the extra overhead of JNA is usually noise if your native code is actually doing any useful work (ie. not benchmarks adding ints together)
Your argument is spurious because you’ve had a quick look at JNA and think you understand it - hint, worrying about Native.loadLibrary() means you don’t understand why that really isn’t a problem, and if you had performance concerns you’d never use Native.loadLibrary() anyway.
If you want to learn JNI, go for it! If you want a quick way to answer your main question, have a look at what already exists.
Referring to yourself in the third person?! … :emo:
If you want toy around with jni and win32, by all means go ahead.
Just don’t expect to get any benefit other than you’ve learned something…