Develop Bugs

Silverlight/XNA App development section of the forum

As per title,
Having never writting apps before, I thought I'd have a go at downloading Expression studio (mainly due to it being free for students )
Seems pretty easy to get the hang of and these tutorial videos to follow are pretty handy http://microsoft.com/design/toolbox, it would be nice to maybe have a section of the forum for developing apps in Silverlight
Espescially seeing as deploying apps directly to your phone in Visual Studio seems to be the only way to side load apps at the moment.

This is the right section, as soon as I can make clear that this section is not intended for general chat but actual software development questions

ok so, pulling the silverlight and xna libraries out of the emulator and cooking them into wm6.5.5 i now need a way to test if these libraries are valid.
anyone interested in compiling a simple test for these? it seems the xna game, input and core libraries are there as well as silverlight browser and ui stuff.
very interested to see how valid these libraries are if at all

norgan said:
ok so, pulling the silverlight and xna libraries out of the emulator and cooking them into wm6.5.5 i now need a way to test if these libraries are valid.
anyone interested in compiling a simple test for these? it seems the xna game, input and core libraries are there as well as silverlight browser and ui stuff.
very interested to see how valid these libraries are if at all
Click to expand...
Click to collapse
Ha love this way of thinking, how to get new stuff running on old stuff.
Reminds me of this big community i have heard of.

Sorry dude but I'm very sure this won't work.
First up, the files have dependencies (namely CE7 and other core files must use the CE7 API). You can't get around this without source code.
Secondly, the files from the emulator have ARM headers but use x86 code, as far as I know.

Thanks!!
You can find a whole bunch of silverlight projects to download here http://silverlight.net/community/samples/silverlight-samples/

Noonski said:
Ha love this way of thinking, how to get new stuff running on old stuff.
Reminds me of this big community i have heard of.
Click to expand...
Click to collapse
thinking without restricted boundaries, it may not work and i may be waaay off, but then again....it may just work lol and if not i've lost nothing.
the silverlight causes issues and i am sure there is more to xna than just the framework dll's. will be interesting to try and call functions within them and see what happens either way.

[GUIDE] libGLES_CM.dll is deprecated for modern versions 1.x of OpenGL/ES

[GUIDE] libGLES_CM.dll is deprecated for modern versions 1.x of OpenGL/ES
After investigating this matter myself, and reading some user postings on the internet, I think that there is a widely shared misunderstanding concerning valid OGL/ES 1.x dll's on modern PDA's and phones. In my experience libGLES_CM.dll often does not work, but the combination libGLESv1_CM.dll and libEGL.dll is perfectly compatible with many OGL/ES 1.x apps. This could be due to the fact that libGLES_CM.dll is an old and deprecated dll of OGL/ES versions below 1.1.09.
In an obscure note, khronos.org writes about GLES_CM (and GLES_CL): "These names are deprecated for OpenGL ES 1.1 and beyond and should only be used for a library that includes the EGL entry points in order to support legacy applications.". And about GLESv1_CM (and GLESv1_CL): "These alternate names for GL ES libraries that do not contain the EGL entry points were introduced starting at revision 1.1.09 of the OpenGL ES 1.1 specification.".
In real life, this means that programmers should generally link with libGLESv1_CM.lib and libEGL.lib instead of with libGLES_CM.lib for OGL/ES programs to work on modern OGL/ES 1.x WINCE phones. I tested this on the HTC HD2. Existing apps for libGLES_CM.dll should possibly be recompiled that way to work. It is a very small and effortless adaption.
Please don't build ROM's with custom OGL/ES dll's in ROM that are not compatible with the new 1.1 implementation. The situation is already not so clear, and you may make conforming OGL/ES apps unusable; as I have experienced. For a software upgrade this could be acceptable, but don't put them in ROM.

While indeed on a number of newer devices the libGLESv1 / libEGL combo is present, on most older devices it is not. The vast majority of OGL/ES (CM) 1.x apps available on WM are statically linked to libGLES_CM. What is often the case on newer devices is that libGLES_CM in fact proxies to libGLESv1_CM / libEGL, and in case of OGL/ES v2 devices the libGLESv1_CM then translates/proxies v1.x code to v2.x code in libGLESv2.
The modern devices like the HD2 implement all of these. Linking to one or the other should not make a difference, only for legacy/compatibility reasons. In fact, static linking to either of them is a bad idea. A correct modern OGL/ES v1.x app would dynamically try to load libGLESv1_CM / libEGL, and if that fails, dynamically load libGLES_CM. Then it would first try requesting a config with all the wanted attributes, and if that fails try requesting a config without any selected attributes at all, and walk through the resulting available configurations to manually pick the best one.
That ^^^ is the only way to make an OGL/ES v1.x app work on virtually all OGL/ES v1.x supporting devices on Windows Mobile. Due to all the various (also stock) ROM 3D driver issues, and implementation differences between manufacturers, statically linking to one of the libs is always a bad idea - unless you don't mind that it doesn't run on older devices.
As for recompiling existing apps, that just isn't going to happen. Though of course a proxy libGLES_CM driver would be easily buildable.
As for building ROMs, of course all these drivers are interlinked. Unless the chef really knows what he's doing, the entire set ( libGLES_CM, libGLESv1_CM, libEGL, optionally libGLESv2, not to mention all the support drivers, which on the Snapdragon platform are quite a large number of them) should always come from the same OEMDrivers source.

Chainfire said:
What is often the case on newer devices is that libGLES_CM in fact proxies to libGLESv1_CM / libEGL, and in case of OGL/ES v2 devices the libGLESv1_CM then translates/proxies v1.x code to v2.x code in libGLESv2.
Click to expand...
Click to collapse
As I wrote, in my experience with a number of OGLES V1.x applications, this just does not work on the HTC HD2. Interestingly, examples from the Khronos SDK are linked to the new libs and they do work. But in the project file, the Vase example, and probably all examples, is linked with the old lib and does not work when compiled that way. Recompiling it with the new libs works again.
Another example is GLUT|ES; it won't work with libGLES_CM.dll, but it does work with libGLESv1_CM.dll and libEGL.dll.
To be safe, programmers may in general as well link to the newer libs if they know that they are available on devices. If even Khronos does not get it right in the SDK, something is probably wrong with libGLES_CM.dll for many newer v1.x apps.
"A correct modern OGL/ES v1.x app would dynamically try to load libGLESv1_CM / libEGL, and if that fails, dynamically load libGLES_CM."
Given what I wrote above, I doubt that failsafe tests can be done that way. I also think that trying to make libs forward compatible that way probably has more disadvantages than advantages. It is arguably bad practice.

zzxq said:
As I wrote, in my experience with a number of OGLES V1.x applications, this just does not work on the HTC HD2. Interestingly, examples from the Khronos SDK are linked to the new libs and they do work. But in the project file, the Vase example, and probably all examples, is linked with the old lib and does not work when compiled that way. Recompiling it with the new libs works again.
Click to expand...
Click to collapse
I've not run into a widely used OGLES v1.x app that did work on older devices (libGLES_CM) but does not work on my HD2 (also libGLES_CM, but libEGL + libGLESv1 -> libGLESv2 internally). However you should keep in mind that very few use the actual libs provided by Khronos, as they are known to cause issues. Most use custom libs (there are some on XDA) that do work properly. Perhaps there is something wrong with your HD2 / ROM specifically?
Another example is GLUT|ES; it won't work with libGLES_CM.dll, but it does work with libGLESv1_CM.dll and libEGL.dll.
Click to expand...
Click to collapse
It does. I've used GLUT|ES apps on WM, but again, probably not built against Khronos libs.
To be safe, programmers may in general as well link to the newer libs if they know that they are available on devices. If even Khronos does not get it right in the SDK, something is probably wrong with libGLES_CM.dll for many newer v1.x apps.
Click to expand...
Click to collapse
And get two different executables? No thanks. While indeed it is probably true that the existing libGLES_CM implementations are not completely according to spec, they do work if you know how to handle them (they have their quirks). People have been developing cool and working apps for them for several years.
"A correct modern OGL/ES v1.x app would dynamically try to load libGLESv1_CM / libEGL, and if that fails, dynamically load libGLES_CM."
Given what I wrote above, I doubt that failsafe tests can be done that way.
Click to expand...
Click to collapse
This is a tested and tried method that works across virtually all OGLES 1.x supporting WM devices, and is relatively easy to implement.
I also think that trying to make libs forward compatible that way probably has more disadvantages than advantages. It is arguably bad practice.
Click to expand...
Click to collapse
Whether it is bad practise or not is completely irrelevant. It is the only practical way to create compatibility, and is actually in use on several devices and ROMs.
Developers of older apps will not recompile their apps because you want them to, as it would make them incompatible with older devices, and it does work on the newer devices as well, if they did their job right. Nor will ROM chefs change the drivers the way you want them to, because the existing way works if you treat it right, and maintains compatibility with older apps - which is what the users want. It's just simply not going to happen. Not to mention that "WM is dead" and nobody is going to invest in making such grand chances this late in the game.
I know you don't believe it, but the current methods do work if you treat them right, and are widely implemented. I get the distinct impression that your "experience" is large based on your own developments and only tested on the HD2.
Believe me, I have "some" experience across over 40 different devices from various manufacturers and various generations over a period of several years. These methods don't just work, they work well across most apps and devices.

Chainfire said:
However you should keep in mind that very few use the actual libs provided by Khronos, as they are known to cause issues. Most use custom libs (there are some on XDA) that do work properly.
Click to expand...
Click to collapse
I assume that you are talking about dll's; not import libs. In my experience, these custom dll's break the libGLESv1_CM.dll / libEGL.dll functionality. Did you test that? That's partly why I wrote this article. Again, the old lib is not supposed to be 1.1. compatible, so I would just leave it as it is.
I understand your reasons; many developers seem to suppose that libGLES_CM.dll is the 1.1 dll. But recompiling is no big deal. I do not care if developers don't recompile existing apps; that was not really the point. They have the option.
Now the false assumption is made by many that libGLES_CM.dll is 1.1 compatible; while on some devices, and officially, it just isn't and libGLESv1_CM.dll / libEGL.dll is. It cost me a lot of time to discover that, and others probably too. Other things being equal, I'd personally rather work according to the offical standard than be dependent on custom dll's that are more compatible in some cases.

[Q] Bluestacks or equivalent for RT?

Rumors are flying that bluestacks will bring their newly touch-optimized app to RT, giving us access to Android Apps. Anyone else heard something similar?
Also, is there any equivalent we could get our hands on right now, like an open-source equivalent that could be ported? It seems ridiculous that to run native ARM apps on an ARM platform we need to port an ARM environment from x86 back to ARM again... there should be a simpler way. All pure speculation of course, but it seems like it should be possible. So, outside of a bluestacks port, how could Android apps be run on an RT device?

Install a Linux kernel and a Dalvik runtime... Seriously, do you realize how silly what you're asking for sounds?
"Why can't we run Linux apps on Windows? It's an x86 processor too..." (Note: Android is not all ARM.)
Stuff like Bluestacks is a huge, complicated project.

GoodDayToDie said:
Install a Linux kernel and a Dalvik runtime... Seriously, do you realize how silly what you're asking for sounds?
"Why can't we run Linux apps on Windows? It's an x86 processor too..." (Note: Android is not all ARM.)
Stuff like Bluestacks is a huge, complicated project.
Click to expand...
Click to collapse
Seriously your a bore

rw6497 said:
Seriously your a bore
Click to expand...
Click to collapse
He's not a bore, he's realistic. It's not his fault that people make outrageous requests all the time and expect them to be fulfilled. I find it quite irritating too, especially when people PM me and ask me again because it's been posted in a thread that it's not possible without an unreasonable amount of work (that we're not going to do on our spare time) and they don't like that answer.
You guys have to remember, we're doing this for free. We're not obligated to port every single program you guys throw at us. If you don't like that, learn how to port them yourselves.

I don't want to spawn an argument...
I'm not asking anything from anyone, I'm just curious about some rumors and inquisitive about possibilities. I'm not all "OMG! netham45! Can u plz make this run android!? And then iOS! And PlayStation games!" I respect netham45 a ton and think his work is amazing.
I'm just opening discussion here.

For comparison, consider the Wine project: well over a decade of development (much longer than Android has even existed) to have an open-source tool that can run many x86 Windows apps on x86 Linux. Or consider Cygwin, which can't even run x86 Linux apps on x86 Windows; they must be recompiled for Cygwin first. Expecting that some equivalent program to run ARM Dalvik/Linux apps on ARM Windows would have just popped out of the woodwork in a usable state - even as usable as Wine, which is nowhere near 100% app compatibility yet - is quite unrealistic.

jtg007 said:
It seems ridiculous that to run native ARM apps on an ARM platform we need to port an ARM environment from x86 back to ARM again...
Click to expand...
Click to collapse
Bluestacks involves ZERO emulation of ARM. Android apps are run inside the dalvik virtual machine (itself a register based version of the java virtual machine). To run an android app just needs a DVM and its class library: bluestacks pretty much does this. Android native code apps do then get complicated yes but then the android NDK has a rather convenient feature that bluestacks can exploit.
NDK compiles native binaries for both x86 and ARMv7 by default (note default, you can over-ride which platforms it compiles for, I believe ARMv6, ARMv6hf, ARMv7, MIPS and x86_32 are available options although I am not 100% sure on the exact arm versions so might be wrong). Bluestacks is only running on x86 and x86_64 machines. x86_64 machines can safely run x86_32 code. So really bluestacks when it encounters a native app "just" has to run the x86 binary the NDK produces on windows/mac with a compatibility layer. Still a complex job of course.
Bluestacks on windows RT could actually take the same shortcut bluestacks on windows and OSX takes in regards to native code, just with the ARM binaries running in a compatibility layer instead of the x86 binaries.
Bluestacks still has to mess about a bit exposing hardware to "android" correctly and handling a few extra bits and pieces but generally it works rather well and in theory could work on windows RT. However in practise it might have some speed sacrifices which will become much more apparent seeming as the guts of most windows RT devices are also the guts of android devices, now you've introduced slowdowns and the RT device will be slower than if it just ran android in the first place, might not be an issue on some less intensive apps but something like shadowgun would probably have noticeable slowdowns. Also I doubt a company like that behind bluestacks wants to develop for jailbroken devices, microsoft certainly wouldnt give permission for something along the same lines to be included on the windows store. The other major issue is OpenGL ES. Non existant on windows RT, bluestacks I believe converts OpenGL ES calls to full OpenGL. We dont have that either. We have directX or software. In theory you could convert the OpenGL ES calls to directX, certainly not impossible, but would certainly be alot of work.
TL;DR. Its theoretically possible to have android apps running on windows RT. There are too many issues to make it viable at this moment in time.
Future updates to what microsoft does and doesn't allow on RT (OpenGLES I'm looking at you) and knowledge/hacks (GLES>DX?) gained as more people take a poke at it might help nudge a dalvik VM on RT in the right direction in future though.

I wonder how relevant this is
http://www.pcworld.com/article/2018...tility-to-run-android-apps-on-windows-rt.html

Interesting, but too early to call "relevant", I think. That article is over two months old; has anybody heard anything since? It's possible that the project is being worked on internally already and will be available soon, but don't count on it.
That said, we now have three ways to get software onto RT:
1. The Windows Store. Official, easy, and can be monetized, but requires Microsoft approval, must run in Metro, and restricts available APIs.
2. Sideloaded Metro app. Semi-official (no hacks needed) but requires going through the (fairly simple and free) process of equipping your device with a developer license. Still runs in Metro and the AppContainer sandbox, but you can somewhat ignore Microsoft's approval process and use any API that is reachable.
3. ARM-compiled desktop app. Requires a jailbroken device, which MS could later try to block, but for now it's easy. No API or sandbox restrictions, aside from the lack of certain features (like OpenGL) on RT.
I wonder which one Bluestacks would choose? #1 is the most beneficial to them, if they can do it, and if MS rejects it they could always go with #2 as a fallback. #3 is the easiest for them, most likely, but carries the most risk. There's also, of course, item #4: forget RT, and keep going with x86 Windows and OS X, where all the customers are.

I dont think they would actually have to go as far as option 3. ModernUI would probably be more than enough for bluestacks.
I wonder if microsoft would try and prevent bluestacks from the marketplace. I guess as far as they are concerned it might improve the image of their devices if they can run android apps too (minimizing costs of migration to RT from android for enterprise customers too, although it seems ipad's took off mostly in enterprise).

[Lib][Java/JAR] RegIOLib - Java/Registry In/Out Communications Lib

Hey there,
I thought it was time to release something new
A bit of background storyline:
My last projects were all VB/.Net programs, and they were somewhat great, sure. But I was missing the Linux portability and the programs aren't available on all Windows version - Which bugged me a lot. So I finally started coding in Java again! I'm also porting Universal Android Toolkit to Java, so I can easily create a Linux version of that as well.
(If you want to make that happen faster, please donate to me. I managed to fix my laptop, but I've only got a 60GB HDD and I need that much space alone for Windows and I have no income, I'm only 16 )
Anyways, now that you know where I'm coming from, as I'm porting Universal Android Toolkit to Java, I need access to the registry to save the application's settings and easily access them. But unlike .Net languages, Java doesn't have built-in support for this kind of operation, so I looked around and grabbed bits and pieces of code and stuck them together into a Java Class Library.
Thus, RegIOLib was born.
It's licensed under the GPL 3.0 (License info included in the source).
Downloads
Sourceforge
Source Code
http://github.com/Beatsleigher/RegIOLib
EDIT:
I forgot to mention the following: To get access to the Windows registry, the application needs to be started with administrative rights!
You can either achieve this by starting the app via a launcher (Which is what I tempt to do) or by right-clicking the file and allowing it to run as admin.

Beatsleigher said:
It's licensed under the GPL 3.0 (License info included in the source).
Click to expand...
Click to collapse
So closed source applications may not use it?

nikwen said:
So closed source applications may not use it?
Click to expand...
Click to collapse
Of course they can use it
Just add a link to this thread and my website, done.
But if you're coming from some major company or something, then I would like something more

Beatsleigher said:
Of course they can use it
Just add a link to this thread and my website, done.
But if you're coming from some major company or something, then I would like something more
Click to expand...
Click to collapse
According to the GPL they can't because it requires the source code of derivative work to be published. That's the "problem" with that license if you use it for libraries.
Due to that the LGPL exists.

http://www.tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3)
Limited commercial use. Must include source code. So no, GPL libraries and closed source applications do not mix.
An inelegant solution (which is the one I have always used actually) is to save settings in a file in %APPDATA%, no admin rights are required to edit files in there, or roll your own registry library for the application. Or Beatsleigher could LGPL it, but its his project, his license, I think he has full right to stick it under GPL if he wants to.
Although I dont think saving into a registry key is really cross platform Neither is %APPDATA% but using the %APPDATA% method is simple file read/write so on a cross platform application you can simply change the filepath dependent on the current execution environment.
System.getenv("APPDATA") will return the filepath for the current users APPDATA folder on windows. System.getProperty("user.home") works on linux and I think OSX to get the home directory. I dont think user.home works properly on windows. But it should be easy to switch between the 2 methods, add on an extra bit for where your settings file is and detect which to use at runtime.
Disadvantage (and to some advantage, depends on what the application is doing and whether the author likes it or not) is that saving configuration files as actual files means the user can play around with them. APPDATA is by default a hidden folder. But chances are most users dont even know what the registry is so in a way your settings might be more secure left in there.
Even possible to have an application load settings from the registry on windows and files on everything else.

SixSixSevenSeven said:
Or Beatsleigher could LGPL it, but its his project, his license, I think he has full right to stick it under GPL if he wants to.
Click to expand...
Click to collapse
Of course, he has that right. It's his code. The GNU even collected some reasons for sticking with the GPL.
Just wanted to point out that the GPL says that all derivative work (which includes programs that use libraries licenced under the GPL) must be GPL'ed (and therefore open source'd), too.

SixSixSevenSeven said:
http://www.tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3)
Limited commercial use. Must include source code. So no, GPL libraries and closed source applications do not mix.
An inelegant solution (which is the one I have always used actually) is to save settings in a file in %APPDATA%, no admin rights are required to edit files in there, or roll your own registry library for the application. Or Beatsleigher could LGPL it, but its his project, his license, I think he has full right to stick it under GPL if he wants to.
Although I dont think saving into a registry key is really cross platform Neither is %APPDATA% but using the %APPDATA% method is simple file read/write so on a cross platform application you can simply change the filepath dependent on the current execution environment.
System.getenv("APPDATA") will return the filepath for the current users APPDATA folder on windows. System.getProperty("user.home") works on linux and I think OSX to get the home directory. I dont think user.home works properly on windows. But it should be easy to switch between the 2 methods, add on an extra bit for where your settings file is and detect which to use at runtime.
Disadvantage (and to some advantage, depends on what the application is doing and whether the author likes it or not) is that saving configuration files as actual files means the user can play around with them. APPDATA is by default a hidden folder. But chances are most users dont even know what the registry is so in a way your settings might be more secure left in there.
Even possible to have an application load settings from the registry on windows and files on everything else.
Click to expand...
Click to collapse
No, as far as I'm aware, only Windows has a registry. I could be wrong though. In the past 5-6 years that I've been developing, I was only developing in VB.Net - A decision that I highly regret nowadays
But I'm so used to being able to save my settings in the registry where no 'normal' user can modify them and cause the program to misbehave, that I'd like my java programs to do so as well.
And seeming as Universal Android Toolkit is a big, big project (I've been developing it for over a year now and I'm constantly adding new features and now I'm porting it to Java making it really hard to release, but I'll get there eventually.
As soon as I've got the major stuff sorted out, I think I'm ready to release a Pre-Release candidate for testing and bug-fixing, but like I said, I'm still having some trouble and then I need to figure out a way to get those settings saved on Mac OS and Linux machines, for which I've already written some classes, but only to install ADB and stuff... And I'm getting side-tracked again, aren't I?
Anywhosers, I think I'm going to leave it under the GPL, even though you're right and that that means that closed-source programs can't use it, but I'll think of something. Even if it's a commercial license, say someone pays 2$ per program. I don't know.
But for the thing you said with %AppData%, what you can do on Linux machines, is (in Java)
Code:
private final String userProf = System.getenv("user.home");
final File tempDir = new File(userProf + "/Temp/(.)<Program>/temp.file");
private void setupTempDir() {
Path tmp = tempDir.getParentFile().getPath();
if (!tmp.exists()) {
tempDir.createNewFile();
}
}
That should solve that problem, then you COULD create some sort of settings file, but then it's just a pain to get and save the settings when you're using multiple GUIs, like me.
And then there's another way of doing that in Android apps, which I haven't figured out yet, mainly because I haven't even started with Android apps and I don't have the hard drive space to do so :/

Beatsleigher said:
Anywhosers, I think I'm going to leave it under the GPL, even though you're right and that that means that closed-source programs can't use it, but I'll think of something. Even if it's a commercial license, say someone pays 2$ per program. I don't know.
Click to expand...
Click to collapse
OK, no problem. The GPL, however, says that you may not relicense it. :/
(All of my comments I've posted yet sound as if the GPL is a bad license. To clarify that: I don't think so. I prefer it for applications, but use the LGPL or Apache v2 license for libraries.)

Beatsleigher said:
(If you want to make that happen faster, please donate to me. I managed to fix my laptop, but I've only got a 60GB HDD and I need that much space alone for Windows and I have no income, I'm only 16 )
Click to expand...
Click to collapse
I'm 17 and I have a 64GB SSD. C#, C++ works great.
Anyway 700 lines of license make no sense. The same about the portable registry library for linux. Could you tell the purpose of it?

Useless guy said:
I'm 17 and I have a 64GB SSD. C#, C++ works great.
Anyway 700 lines of license make no sense. The same about the portable registry library for linux. Could you tell the purpose of it?
Click to expand...
Click to collapse
GPL isn't 700 lines last time I checked, also I left a link to a simple description of it above (I do love tldrlegal).
There is no registry for linux, no one mentioned a portable registry for linux.

SixSixSevenSeven said:
GPL isn't 700 lines last time I checked, also I left a link to a simple description of it above (I do love tldrlegal).
There is no registry for linux, no one mentioned a portable registry for linux.
Click to expand...
Click to collapse
I did
Anyways, now that you know where I'm coming from, as I'm porting Universal Android Toolkit to Java, I need access to the registry to save the application's settings and easily access them.
Click to expand...
Click to collapse

nikwen said:
OK, no problem. The GPL, however, says that you may not relicense it. :/
(All of my comments I've posted yet sound as if the GPL is a bad license. To clarify that: I don't think so. I prefer it for applications, but use the LGPL or Apache v2 license for libraries.)
Click to expand...
Click to collapse
I'm working on a license for it and any other such things. So I'll release it again for commercial and closed-source programs when it's done.
And yes, it does sound like you think it's a bad license. But meh. Everyone has their own opinion, I guess.

Useless guy said:
I'm 17 and I have a 64GB SSD. C#, C++ works great.
Anyway 700 lines of license make no sense. The same about the portable registry library for linux. Could you tell the purpose of it?
Click to expand...
Click to collapse
GPL isn' 700 lines.
That's cool for you, that you've got that stuff. I don't. Anyways, I'm getting away from .Net languages, and C# is easy for anyone to learn. Especially if they're coming from VB, like me.
C++ isn#'t my kinda thing, as you can't natively create GUIs in it. You always need some kind of library for that sort of stuff.
And I didn't intend this for use with Linux. Everyone that has basic knowledge of these operating systems knows that Linux, BSD, Mac OS etc. don't have registries. And I never even noted that I'm attempting to use registry stuff in Linux. I said I'm porting Universal Android Toolkit to JAVA, and that I need access to the WINDOWS registry to save the application's settings in the reg, so that users can actively change the settings if the program starts misbehaving.

Useless guy said:
I did
Click to expand...
Click to collapse
I said JAVA, not Linux. What I probably did say, however, is that I'm porting my program to Java so that it can easily be ported to said OSs. But never that I'm attempting to save my settings in the registry in all OSs.

Beatsleigher said:
C++ isn#'t my kinda thing, as you can't natively create GUIs in it. You always need some kind of library for that sort of stuff.
Click to expand...
Click to collapse
Lolwhat?

Beatsleigher said:
C++ isn#'t my kinda thing, as you can't natively create GUIs in it. You always need some kind of library for that sort of stuff..
Click to expand...
Click to collapse
Errm, those libraries are written in C or C++... native code such as C and C++ are the only languages which can create GUI's. VB.net/C#/anything else .NET use libraries too which in the case of WinForms and WPF are just wrappers around win32 functionality implemented in C.

Beatsleigher said:
And yes, it does sound like you think it's a bad license. But meh. Everyone has their own opinion, I guess.
Click to expand...
Click to collapse
I love the GPL. I use it for everything (except libraries).
But I'll stop the off-topic now.

android 2.1 app dev environment

i find that i prefer using my nst more & more.. in fact, my swanky but gas-guzzling tablet has been all but discarded, except for watching movies in bed.
i am going to find open-source apps, and recompile the latest sources specifically for android 2.1 eclair, as i find that most devs and google market are removing eclair from their horizons. i am particularly interested in small-sized efficient apps. i do use quite a lot of them, but mostly very old versions.
for this purpose, i want to setup a eclair-dedicated dev environment. i am happy to share all apps that i compile & use myself. hopefully, many others might find useful too.
where i need your help is with advice on how best to setup a tiny/efficient (not bloatware) dev environment, bearing in mind that it will only be used to recompile apks for eclair on b&w eink. i notice that some of you are very efficient in creating extremely small apk, and this is what i want to do.

platform:
on my debian wheezy host, i installed virtual box and created a debian wheezy minimal guest. virtualbox guest additions has significantly altered my perception of virtualbox. i had been using kvm previously.
pre-requisites:
install openjdk-7-jdk
dev environment:
google lists android studio as the only official one. it is huge, bulky, cumbersome bloatware imho. i think this is targetted at the new kids on the block not used to terminal environments. but this seems to be my only option for now, till i hear from you lot of some simpler dev tools.
my requirement is very simple, all i need to do is, change some code somewhere and compile.
so i downloaded android studio, and unpacked it in a directory reserved for my android development. loading it is like watching windows booting up! and then it downloads android sdk, which is another huge bloatware, particularly since it insists on downloading all the crap-lollipop-ware which i have no intention of using.
so my dev environment is almost ready! if anyone has suggestions or tips, or want more detailed instructions/commands, please comment..

Don't forget that the NST only runs 2.1 Éclair apps, as its OS is 2.1 Éclair.
This sounds like a great project - I also prefer my NTG (in fact, I'm on it right now!).

veloo said:
for this purpose, i want to setup a froyo-dedicated dev environment.
Click to expand...
Click to collapse
Check requirements for compiling Eclair/Froyo itself, SDK version doesn't matter since it supports all API versions.
Personally I'd use a virtual machine with oldest supported 32-bit *buntu release- better chance that required packages versions will be present in official repos.
EDIT:
This may help, discussion was related to kernel compilation however there should be link to quick tutorial about CM6 (Froyo) compilation- http://forum.samdroid.net/f28/setup-kernel-build-environment-using-virtualbox-windows-7-64-bit-4007/ (sorry if 10-sec advertisement pops up)

thanks folks.. my bad! indeed it is eclair, and not froyo. i have updated my op above.

gen_scheisskopf said:
EDIT:
This may help, discussion was related to kernel compilation however there should be link to quick tutorial about CM6 (Froyo) compilation- http://forum.samdroid.net/f28/setup-kernel-build-environment-using-virtualbox-windows-7-64-bit-4007/ (sorry if 10-sec advertisement pops up)
Click to expand...
Click to collapse
that discussion seems to be about iphone development

veloo said:
that discussion seems to be about iphone development
Click to expand...
Click to collapse
Nope, it's for Samsung i5700 Spica (latest official firmware- 2.1)

all that talk about crosstool toolchain arm-iphone-linux-gnueabi got me confused.. sorry!

No problem. Back then we had to use whatever was available and compiling Crosstool-NG was easier option than to get precompiled Android toolchain.
Anyway check links in the thread, there were tutorials about compiling Froyo from scratch (note: samdroid's wiki is down) and IIRC Eclair had about the same requirements

thx but my objective atmo is not compiling froyo or eclair or any roms. it is purely to compile apps for use on the nook.

I'm aware of that. IMO link provided can help you in preparation of build environment

At work I use Android Studio to build apps, but at home I still just use Notepad++, the Windows tools in the Android SDK and the (ancient) Borland make.
I probably will migrate to Android Studio at home eventually.
Still, coding by hand you learn a lot about things.

In the old days for text editing very large data files I used VE & Vedit plus the old Norton commander file manager, I could select any sort of columns within a text file in VE, hex, plus grep commands. Or ms-word macros with VB APIs if needed too. But these were for huge files from publishers. For most things though I had been using Notepad++ or UltraEdit for years. In recent past I hardly use them, instead I use Sublime Text Editor for almost everything, I like the recent portable version which launches fast. Also if I'm debugging live with breakpoints & watches & changing code in PhpStorm, the open instance of Sublime updates code as I work in PhpStorm. I tried a few modern text editors in the same league which supposedly have bested Sublime, but I keep going back to it for most coding or text. Apart from php and various text formats, Sublime handles & color codes for other types too like html, JavaScript etc. Interesting discussion on modern text/code editors & IDEs:
https://www.youtube.com/watch?v=5K-TalfLFas

Hey a nice effort to build apps optimized for Nook Simple Touch.
Renate, Marspeople, have already created some nifty apps for our device.
How about you update the OP with links to their apps(with due credit to them and express permission for the same) besides sharing your own collection of NST optimised apps ?

I'm totally noob at this, My little dream it's develope a clock app for the nook but I'm stuck in "hello world" when I try to compile my app in Android Sudio 2.1.3 it throws this error: "uses-sdk:minSdkVersion 7 cannot be smaller than version 9 declared in library" Can somebody help me?
I

Use SDK suite ver. 9 and higher or declare in library, that you're using ver.7.

Necropost, I know, but do you hhave links to posts by the people mentioned, with the apps they've developed?
aiamuzz said:
Hey a nice effort to build apps optimized for Nook Simple Touch.
Renate, Marspeople, have already created some nifty apps for our device.
How about you update the OP with links to their apps(with due credit to them and express permission for the same) besides sharing your own collection of NST optimised apps ?
Click to expand...
Click to collapse