Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (542)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (604)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  3DzzD, JOGL support planned  (Read 9363 times)
0 Members and 1 Guest are viewing this topic.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #30 - Posted 2006-02-16 21:37:37 »

popup is a little different but it is still working, really dont understand ??!

How did you get that security warning? Did you re-sign any of the jar files? You shouldn't be able to claim that your applet (note your name at the top of the security dialog) is signed by Sun Microsystems. Maybe this is a bug in the security dialog code.
Offline DzzD
« Reply #31 - Posted 2006-02-16 21:58:28 »

!?!!?.?,

 I really dont know and only notice that the popup said my applet was signed by sun when i update to lastest jvm before i dont really read the security dialog maybe it was the same, dont know exacly?! to be true I dont understand what append!


Bruno

Offline kylix999

Junior Devvie





« Reply #32 - Posted 2006-02-16 22:00:07 »

MR KEN RUSSEL please be so kind and answer one my question:

Is it possible to add one small class file to jogl.jar like JoglAppletLancher to jogl-src\jogl\src\classes\com\sun\opengl\util

What to add?

Well a simple class file that will enable silent instalatin for unsigned applets who would like to choose whatever they want download jogl support or not especially when that applet would like to have its own software renderer. When user would like to have jogl support it will donwload on its own  jogl.jar and next step of instalation will be the same as in JoglAppletLancher.

How i imagine that?

first i have my own unsigned applet which is quite little becouse it has its own software renderer, when user decide to use jogl support My applet on its own download
jogl.jar and create instance of joglInstaler (code below, that must be added to jogl.jar ), interface is neccesary to handle connection betwean my app and jogl.jar, so my app load class joglInstaler using  ClassForName and newInstance() to initalize it and then invokes installJoglAndGetMyListener function as a argument it will pass
MY own class file as byte array that supports jogl (using GLEventListener etc, for example like has made it Dzzd in code example above) . This function will install jogl on client machine initalize that my class file i mention earlier and return it to my app. So my app will be also able to use func display from jogl (GLEventListener )


interface{
     GLEventListener installJoglAndGetMyListener( byte joglProgram[]  ); 
}


class joglInstaler implements JoglInstall
{
    GLEventListener installJoglAndGetMyListener( byte joglProgram[]  )
    {
         .... install native libs
         .... initalize class from byte array -> joglProgram[] ,  i think that byte array it is good solution becouse my applet
              could download  my own class supporting jogl  from server when it will be really neccesary (for example when usser would like to enable jogl)
        ..... initalize as new instance that class
        ..... return it as interface
         
    }

}

I am very sorry that i gave an idea not working code, but i was thinking for a solution for enable unsigned smalll applets to have jogl support when user want it,
well adding one additional file to jogl.jar should not be a problem since it is already signed.

So again what do you think Ken
 
Ok i go sleep...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #33 - Posted 2006-02-16 22:18:55 »

This sounds like a good idea but you or someone else in the community will have to prototype it. c_lilian did an excellent job with the current JOGLAppletLauncher and another effort like that would be needed to generalize it a little bit more.
Offline DzzD
« Reply #34 - Posted 2006-02-17 00:10:07 »

Ok, I uninstall java and than re-install, remove all dll every where with JOGL*.* about one hour of work and finally demo do not work anymore same bug as others.

To work the native dll must be in java lib directory or windows system directory maybe

But it is a really starnge bug that my browser said me my applet was signed by sun!?!

anyways, If we found a simple way to put the correct native library on user java lib folder, all things will work very well without further need for the user to accept a certificat.

why jogl do not do it by itself if it is signed? rather than looking in the java library, it only need to download the native library on request maybe a method like checkLibrary and instalLibrary will do the job?

Bruno

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #35 - Posted 2006-02-17 05:00:55 »

why jogl do not do it by itself if it is signed? rather than looking in the java library, it only need to download the native library on request maybe a method like checkLibrary and instalLibrary will do the job?

JOGL is an OpenGL binding, not a distribution mechanism. We recommend Java Web Start for deploying applications using JOGL and Java Web Start takes care of all of these installation, caching and versioning issues transparently. We supplied the JOGLAppletLauncher more or less as an experiment to see how well 3D applets would work. In general we are not going to get into the business of supplying installers because every application that doesn't 'use Java Web Start has different requirements. However, if you or someone else want to generalize the JOGLAppletLauncher a little more to work in slightly different contexts, that would be fine and welcomed.
Offline kylix999

Junior Devvie





« Reply #36 - Posted 2006-02-17 07:12:15 »


Ken i am happy that you give us an opportunity to make such code, i will make it in a couple of days time , code will be based partly on JoglAppletLancher c_Lilian code. After i will test it that works and post it to javagaming, so people will be able to check it etc, again thanx Ken.


DzzD now when nothing works you Grin you can finally check how real JoglAppletLancher code works please go to this site and say if it works (if you again have not install jogl manually it should work ):
https://jogl-demos.dev.java.net/applettest.html

a cool game also from c_lilian at javapause.com

how to make a true jogl applet please check source code from jogl-demos - gears applet
Offline DzzD
« Reply #37 - Posted 2006-02-17 07:24:29 »

yep, I know it is works I already did the test, but somthing annoying is jogl.jar in applet tag like <applet archive="myappl.jar,jogl.jar..., also works if the dll are in place and jogl.jar is about 800kb when dll is about 60ko, so why jogl.jar isn't able to load it properly if he have already the right to load native lib?! an applet can use the jogl.jar without problem including the fact that it load native library but noway to tell him to load it from networks, it is like having a "porche with bycicle tire" just 60ko (native library) are missing to make it usable in applet.

what has dislike in the JOGLAppletLauncher , wich is great, is the fact that it embed the applet, I dont like this way.

Bruno

Offline kylix999

Junior Devvie





« Reply #38 - Posted 2006-02-17 08:45:53 »


joglAppletLancher id designed to work on top of your true applet, so as in that example with gears demo applet on official page works inside JoglAppletLancher, and about that porshe.. it is agood idea to store everything in one file, Dzzd would you be so kind and check how the full jogl.jar will have size when you add inside it ALL native jars for win, mac linux solaris. Just for example in winrar add those files to the jar. I think that the final size of that jogl+natives will be around 1,2 mb, becouse jogl today is about 900 kb , well i guess it is good to check, but i think that creating sperate files is good for testing etc...
Offline DzzD
« Reply #39 - Posted 2006-02-17 08:48:15 »

....

I was talking about remote loading the library when not present in the user computer......

like a new static method in the jogl.jar loadJOGLLibraryFromURL("mysit.com/joglnative-win32.jar"); or  loadJOGLLibraryFromURL("mysit.com/joglnative-linux.jar");  etc...

the signed jogl.jar have already the right to load native lib and can be used in applet without the need to sign this applet so remote loading is also possible, just by adding a simple method in the jogl.jar, it will be a much more simple process to use it in applet.



Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kylix999

Junior Devvie





« Reply #40 - Posted 2006-02-17 09:06:50 »


loadJOGLLibraryFromURL -this is also good idea, maybe you could try to implement it by yourself and post it to KEN Dzzd?
Offline DzzD
« Reply #41 - Posted 2006-02-17 09:49:23 »

yes I also like that idea  Grin.

but using to be a hacker long time ago ;-) , there will be a big security hole, maybe it is already the case with the current joglappletlaucher? because you can simple unassemble the jogl (native as the .dll files ) library, patch it with a malicious code like patching the glvertex3f function in the library this way
glvertex3f(....)
{
 ..
 my malicious code
 ..
 old glvertex3f code
 return
}
and re-assemble it and deploy your applet using this new library, so a crc or something like that must be computed by the library loader and only allow validated library to ensure the user a good security.

I dont think sun would appreciate his sign to be used as a virus dispatcher ;-)

Offline kylix999

Junior Devvie





« Reply #42 - Posted 2006-02-17 10:05:37 »

i do not know how certificate works in java (on jre side) but i think that changing any  *.jar which was earlier deployed and certified after adding new class or anytning else (by non sun programeer - hacker or someone else) certificate will not work,  so even new pathched jogl.jar will not be asociated with that certificate becouse they are two diffrent files (old jogl.jar and new jogl.jar). Well i do not know but i think that it works in that way.

and  you have right about joglAppletLancher code ido not know but it is intresting if JoglASppletLancher from certified jogl.jar will run applet from not certified jar (for example your DzzD) , but that not certified jar if could run some special functions for example file func will it cause security issus, better it should be checked or someone could make an applet with untrusted code that will be run as trusted, you know what i mean, so someone could acces client system data download native lib etc,  but i think that Ken and c_lilian has thought about it....
Offline DzzD
« Reply #43 - Posted 2006-02-17 10:14:38 »

I am talking about the native library, not the jogl.jar the jogl.jar  is not modified on my previous explanation only the library as .dll for windows and those library are not signed... so you can patch any function in those native library with a malicious code


Offline kylix999

Junior Devvie





« Reply #44 - Posted 2006-02-17 10:23:45 »

ah yes now i understand you have right, have Ken thought about it? This patched lib could make whatever it want to and if some hacker will patch all os's libs it will make crossplatform virus

i have one question to you Dzzd asociated to your website which is really intresting, have you earned anything from those google ads? Is it enough for handle a server and maybe for some candies Wink? I have hard about other adds programs like amazon etc but do not know much more about it...
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #45 - Posted 2006-02-17 20:09:01 »

c_lilian gave the security issue quite a bit of thought during the development of the JOGLAppletLauncher. It requires that the jogl.jar and jogl-natives-*.jar files all be signed by the same entity. Therefore if the security dialog claims that Sun Microsystems, Inc. is the trusted entity, you can't substitute in native code not signed by Sun.

I exchanged email with a member of the deployment team here at Sun and they indicated that the name and URL of the applet is coming from the AppContext, not the certificate. That's why your applet claimed to be signed by Sun. I don't know if there's a good workaround for this but I think it's definitely a sub-optimal situation.
Offline DzzD
« Reply #46 - Posted 2006-02-17 20:17:59 »

Ok, I better understand now the certificat popup bug.

what about a static function to load native library ?
if both native library and jar must be signed they will not be security problem, so is it a possible solution that can be added to JOGL as a static method ?

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #47 - Posted 2006-02-17 20:28:00 »

Maybe, but again you or someone else in the community will have to prototype this. I'm sorry, but we don't have the development resources to support every kind of possible installation mechanism.
Offline DzzD
« Reply #48 - Posted 2006-02-17 20:34:27 »

Great, I am sure user will love this new functionality.

today someone told me that he can do this job, so we will try to feedback the source code as polish as we can.


Offline DzzD
« Reply #49 - Posted 2006-02-22 12:31:14 »

Ok we finished a first version of a new class to allow remote loading of native library from applet, need to polish it before to post its source code.

the new class is called NativeLibRemoteLoader and have two static methods  NativeLibRemoteLoader.loadFrom(URL) & NativeLibRemoteLoader.loadFrom(String) where the parameter is the url of the remote server to download native library from.

we tested a self signed version of the jogl.jar including this new class, and it works fine and it is really simple to use in applet or others.

To use it in an applet just do the following :

NativeLibRemoteLoader.loadFrom(this.getCodeBase()),

libraries will be downloaded if needed in the same way as JoglAppletLauncher do ( jogl_ext dir in user home) and than loading into system.

your applet tag should look like : <Applet archive="yourjar.jar,jogl.jar" ...

should be ready in few days





 

Offline kylix999

Junior Devvie





« Reply #50 - Posted 2006-02-22 14:47:28 »


i have tried to make it on my own, but only made theoretical load code, even not check it, anyway good that you have make it with succes, and i have a question:

1. how have you implemented loading of jogl.jar ?, using url.openConnection and downloading by hand or just simple Class.forName (so the whole process is made by jvm plugin) . Becouse i was thinking to make it possible applet control of loading of jogl and required natives. Why? Becouse jogl.jar is quite huge so it can freeze applet for long time if that librarys will be downloaded by jvm. The problem is in this aproach to make downloaded jar in bytes to make it work for jvm , well theoretically special classLoader could be made so it will work. This approach could be useful if we would to control the process of downloading on our own applet , so for example during loading jogl.jar user will be able to play game etc and after jogl download+natives game will switch to opengl version. Have you fought about it Dzzd?

2. is loadFrom working in its own thread like in JoglAppletLancher refreshJogl , if yes how an applet will know that jogl install has ended (will for examlpe NativeLibRemoteLoader   invoke some applet func to notify it using reflection )



again its great news
Offline DzzD
« Reply #51 - Posted 2006-02-22 20:35:48 »


a1:
the loading implementation of jogl.jar is up to the user of jogl.jar, jogl.jar cannot contain a function to load itself, for our test we just use <applet archive="jogl.jar,other.jar" ...  .

I think it is also possible to load jogl.jar in background using a separate thread while doing something else on screen : play animation or start game in software mode, at least It is how it should be implemented in 3DzzD.

native libraries will be only loaded if needed : loader test for version diff between already downloaded natives and server version

a2:
no, for now native libraries loading is not done in another thread : loading 60ko take only about 8-16 secondes with a 56 kbits modem.

Also I think that the remote loader is not really specific to applet , no ? and if it is not performing an asynchronous loading  there is no need of applet notification.

what do you think about it?





Offline kylix999

Junior Devvie





« Reply #52 - Posted 2006-02-22 21:04:29 »

i think that you could add some special methods for this NativeLibRemoteLoader so applet creator will have better control what is happening, especialy downloading natives on its own not in your installer, well it should be some choice for applet creator
functions:

 - getNativeJarName()   - that function is already  in JoglAppletLancher, so it should be made public, and rewritten again so even before initalization of 
    NativeLibRemoteLoader.loadFrom use my applet will know what native.jar download and i will be able for example to provide user some progressbar or something, so getNativeJarName function should check client os system and check all native jar names and return String of native jar for this os and applet from itself will have to download that jar on its own

- NativeLibRemoteLoader.loadFrom( byte nativeJar[] ) - when my applet will download native jar on its own it should have a posibility to give it to your loader, implementation of this function can be very simple, the whole array of bytes could be just saved like this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
  private void saveNativeJarLocallyFromByteArray(File localJarFile, byte array[]) throws IOException{
    FileOutputStream out = null;  
     try{
         out = new FileOutputStream(localJarFile);
         out.write(array);
         out.close();
      }finally {
          if (out != null) {
            try {
              out.close();
            } catch (IOException ignore) {
            }
          }
        }    
  }


so loadFrom function will save that bytes as a jar (this is the same situation like in JoglAppletLancher.saveNativesJarLocally func  but of course will be much faster) and
next process of extracting native libs from that jar will be the same like in refreshJOGL function (where JarFile jf = new JarFile(localJarFile); is used) but that long freeze will be avoided. I think that it should be made good and with maximum flexibility, that two functions in future could make our live simpler in coding belive me.

so that were my two cents...

what do you think?
Offline kylix999

Junior Devvie





« Reply #53 - Posted 2006-02-22 21:18:02 »

oh and maybe some two additional functions should be added which are very important:

  public boolean isJOGLInitalized();  // false - instalation has not started, true - instalation was complited without any error

  public boolean isJOGLInstalationTerminated(); // true - jogl can not be used due to some instalation problem

so applets will be able to know if jogl works so all steps of initalization like : creating directory for native.jar, getting native libs, loading them to jvm
IT IS VERY IMPORTANT, note that JOGLApppletLancher checks may times for errors and give the user information through displayMessgae what went wrong, for example during functions operations etc, so applet will know if the procees has ended with success

of course those functions names you can cheange as you wish, you should change them to names that will fit better to your loader class   
Offline DzzD
« Reply #54 - Posted 2006-02-22 21:27:58 »

Making getNativeJarName public could be useful.

doing  NativeLibRemoteLoader.loadFrom( byte nativeJar[] ) will cause the applet unavailable to download natives libraries from another location than the codebase of itself due to browser applet security that do not allow to open connection to other server than the applet provider ?

what about doing :

NativeLibRemoteLoader.getNativeJarName();
NativeLibRemoteLoader.loadFrom(serverURL) //synchronous loading with natives name auto detection
NativeLibRemoteLoader.loadFrom(serverURL,nativeName) //Synchronous loading
NativeLibRemoteLoader.loadFrom(serverURL,nativeName,NativeLibRemoteLoader.interfaceProgressor)  //asynchronous loading in another thread

another thing is that NativeLibRemoteLoader.loadFrom(URL) is able to test natives jar version before downloading and applet wont be able to do because they will not be able to read current natives libraries version.

so maybe we can do:

NativeLibRemoteLoader.getNativeJarName();                                             //for utility purpose
NativeLibRemoteLoader.getNativeLibLocalVersion()                                 //Get local version
NativeLibRemoteLoader.getNativeRemoteVersion(URL)                         //Get remote version
NativeLibRemoteLoader.loadLocal()                                                             //Load local natives version
NativeLibRemoteLoader.loadFrom(serverURL)                                           //synchronous loading with natives name and version diff auto detection
NativeLibRemoteLoader.loadFrom(serverURL,nativeName)                    //Synchronous loading and version diff auto detection

NativeLibRemoteLoader.loadFrom(serverURL,nativeName,NativeLibRemoteLoader.interfaceProgressor)  //asynchronous loading and version diff auto detection


will be good to have Ken opinion about it ?


EDIT:
Yes knowing what is the current status of jogl native is a good thing

may be  isJOGLInstalationTerminated and isJOGLInitalized() can be replaced by NativeLibRemoteLoaderException throwed by all NativeLibRemoteLoader public methods?


Offline kylix999

Junior Devvie





« Reply #55 - Posted 2006-02-22 21:50:23 »


code evrything as you wish for error handling etc, it is not a problem

my idea to mek load form byte array is not to replave your idea of downloading from any location even another then codebase.
BOTH ideas can be useful and BOTH ideas can be implemented - it is not a problem from where applet creator would like to download it - from codebase or any athor location he will decide, so you could make it like this:

loadFrom( byte array[], long date) - applet will give date of native jar which is required for checking date version (like in JoglAppletLancher.getTimestamp func)
 
eh ... anyway interfaceProgressor can also be used, well i thought that applet should have much more control but you decide

you have right Ken should take a look at it ...

thanx again for your work DzzD, good night and good luck untill tomorow
Offline kylix999

Junior Devvie





« Reply #56 - Posted 2006-02-28 19:33:47 »

i would not like to interupt your job DzzD but would like to ask one question: have you finished that jogl loader?
Offline DzzD
« Reply #57 - Posted 2006-03-01 08:31:30 »

it is working but can get enought time to polish/finish it since last time I worked on it , source code is for now still very dirty/bad,

I have to finish an other job and than I ll finish this one, I think it will be fully finished and I will post it in one week and maybe before at the begining of next week.

I have the same problem as everybody wich is a lack of time, sorry for the late....

Offline kylix999

Junior Devvie





« Reply #58 - Posted 2006-03-20 14:34:13 »

?

if you DzzD do not have time i can clean up that code, what do you think?
Offline DzzD
« Reply #59 - Posted 2006-03-21 09:04:59 »

That's a great idea, because I am really busy for now.

Thijs(on this forum) and me have only worked on it few hours including time necessary to instal Ant and other tools requiered to compile JOGL, we cannot found any free time to finish this work before a cupple of weeks, so I will send to you our tests source code wich include a new class NativeLibRemoteLoader and a working sample applet that use it.

What need to be done is cleaning the code(for now it is only bunch of code mixed...), improve security by adding a control of the certificat of the downloaded native libraries, adding other necessary method as we told about in that thread, better implement the security acces control block.

It will be really great if you could finish it , thanks for that proposal !

let me know how can I sent it to you






Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Elsealabs (10 views)
2014-12-28 10:39:27

CopyableCougar4 (17 views)
2014-12-28 02:10:29

BurntPizza (21 views)
2014-12-27 22:38:51

Mr.CodeIt (14 views)
2014-12-27 04:03:04

TheDudeFromCI (19 views)
2014-12-27 02:14:49

Mr.CodeIt (26 views)
2014-12-23 03:34:11

rwatson462 (57 views)
2014-12-15 09:26:44

Mr.CodeIt (47 views)
2014-12-14 19:50:38

BurntPizza (94 views)
2014-12-09 22:41:13

BurntPizza (115 views)
2014-12-08 04:46:31
How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!