Hello everybody,
I got a WP7 Samsung Focus and I want to port my old application to this device and join native forces for WP7
My plan is simple: I'll convert my app into a dll, rewrite new gui in C# (or whatever the way to do it on WP7). I saw multiple posts about calling native code (original from Cris Walsh: http://goo.gl/2Tjks). Then I saw a few posts mentioning that it's impossible etc etc.
So, a few questions:
0) can I do it for my app (I don't need marketplace exams etc, I don't care for that)? I know that some WinAPI could be unavailable/broken, all I ask at this point if it's possible to load and run native dll without changing or re-flashing ROM.
1) ms wants 100$ out of my pocket to be able to deploy to my own device (WTF?!). What can I do to deploy to my phone without paying the crooks? (VS2010 tell me to register there and registration askes for 100$).
2) Is there a sample project I could D/L and run, I have zero experience in C# and I have no idea how to load and call native DLL from managed code in WP7? All these half broken samples are totally useless to me, I simply wanted to working HelloWorld app that loads and runs simple dll.
thanks
0) Yes, what you describe is possible. There are lots of limits, though - WP7 applications have very low permissions, and calling native code doesn't fix that. Unless you need to edit something outside the app's own iolated storage, though, you're probably OK.
1) Aside from the official marketplace account ($100), there are a few options:
a) if you've got an LG phone, they come with a built-in registry editor that can be used to dev-unlock your phone. I forget the exact key you need, though.
b) if you've got a student email address (ends in .edu) you can try registering through DreamSpark. This is free.
c) if you don't mind rolling back to pre-NoDo (7004 or 7008) you can use ChevronWP7 Unlock (instructions available on this forum). If you don't have a restore point that far back you can flash an official ROM for that version.
d) if you don't mind waiting, ChevronWP7 Labs will be available at some point (no ETA that I've seen, but it's been talked about for months) and will provide dev-unlock (but not marketplace account) for a nominal fee.
2) There are lots of apps distributed with source, and most of them will use some native code. You could do a search on this forum for subject lines including the tag "[SOURCE]" and find several (I release source for all my apps). However, I suspect what you'd find most useful is Heathcliff74's guide to WP7 apps that use native code, which is on this forum at http://forum.xda-developers.com/showthread.php?t=1299134. It includes step-by-step instructions.
Hope that helps! I look forward to seeing your app. Also, don't hesitate to ask for help with the actual development; I suck at GUIs and Silverlight but am fairly proficient at C# if you need somebody who knows that language, for example.
There is an ETA for the new ChevronWP7 unlocker:only a few weeks away from launch!
Hi GoodDayToDie
GoodDayToDie said:
0) Yes, what you describe is possible. There are lots of limits, though - WP7 applications have very low permissions, and calling native code doesn't fix that. Unless you need to edit something outside the app's own iolated storage, though, you're probably OK.
Click to expand...
Click to collapse
At this point I want to make a DLL from my simple app and call a few functions that interact with filesystem and network. FS is needed only for simple stuff (loading config file etc) from installation folder and creating some temporary files for local storage. Network is tcp/udp, I guess network should be available.
GoodDayToDie said:
1) Aside from the official marketplace account ($100), there are a few options:
...
Click to expand...
Click to collapse
I did some search, it seem that I've done that part. Chevron dev unlock was pulled out from their site, but the old version remains scattered all over the board. There is a good thread a good thread on how to do it. It happens that my phone is 7004. Where can I get old ROM in case if something goes bad and I need to re-flash? Is it easy, am I risking to brick and loose my phone?
I just tried to run sample phone app and it runs on the phone. Initially it said that it was revoked by MS, I run dev-unlock one more time and now it works.
GoodDayToDie said:
2) There are lots of apps distributed with source, and most of them will use some native code. You could do a search on this forum for subject lines including the tag "[SOURCE]" and find several (I release source for all my apps). However, I suspect what you'd find most useful is Heathcliff74's guide to WP7 apps that use native code, which is on this forum at http://forum.xda-developers.com/showthread.php?t=1299134. It includes step-by-step instructions.
Click to expand...
Click to collapse
I'll try to search, hope I'll be up and running soon. Too bad WP7 is DOA. They always had much better tools than all these ghetto Symbian/Android/Xcode crapware tools... WTF is wrong with these guys, at the point when they were surpassed at speed of light by newbies iPhone and Android they made some backward steps to cut off most of the devs (but they added all these 500K Silverlight newbie devs...). I'm so disappointed with Android, seems like they hired all these retards who were fired at symbian: same **** tools
I downloaded a few samples and it seems that all of them contain prebuild dll's and all of them are COM dlls or something like that.
What I'd like to find is simple sample that contains src code to native WinMo dll and C# project that it uses.
As far as I know native dll cannot be build with latest tools (am I right?), but I can use cegcc or VS2008 to build native DLL's.
stuff like:
Code:
if (ComBridge.RegisterComDll("ComFileRw.dll", new Guid("EEA7F43B-A32D-4767-9AE7-9E53DA197455")) != 0)
is totally unknown to me. I would really like to avoid to even elarning anything about COM related stuff. I prefer not to mess up with code that isn't portable.
HI mtlgui,
unless Heathcliff finishes his WP7 Root Tools SDK, you don't have any other way to access native c++ code besides using COM. DFT (The DarkForcesTeam) released a firmware loader, that allows you to flash customized unsigned firmware. They were also able to do some native c++ coding with the WM API. However the used firmware for that is not public and it is limited to HTC devices.
Did you already consider to write your application in c#? Mango has now TCP/UDP socket support for outgoing connections. Incoming connections or services running on the phone aren't possible without using native code, at least for the moment.
Hi rudelm,
if the only way to use native is to build COM dll, then I'm OK with that. My app code is old and I'd rather throw my WP7 device to trash can than trying to rewrite my app in C#.
Eventually, down the road while hacking maybe I'll learn c# well enough to do anything with it other than GUI and calling native/COM dlls.
So, just to confirm my understanding. I need to write COM dlls that access native API (socket, filesystem, wavein/waveout etc) and then load these COM dlls and call their functions from C# (or whatever is the closest lang to c/c++ in the WP7 world).
@mtlgui:
You've pretty much got it. A few thoughts, though:
There is a webserver project available on this site. It includes source for its C++ native component (the library is called NativeIO; I can probably send you the source if you can't find it). It exposes registry, filesystem, and TCP server and client sockets to COM. Note that because this library was built for pre-Mango phones, just compiling it and shipping it may not work on Mango phones as many deprecated libraries were removed in Mango and if the DLL contains any references to them, it won't load.
Generally speaking, what you're asking for with TCP/UDP is possible, though you may have to code against the winsock API directly. It sounds like you're doing as little as possible with C#, so even if the Socket API that is available with Mango were sufficient for your app's needs, you wouldn't be using it.
Filesystem access... even if you have read access to your app's install folder (I haven't checked, though you should), you almost certainly won't have write access. Each app does have a writable "isolated storage" though, under \Applications\Data\{GUID}\Data\IsolatedStore\. I've only ever tried writing to it using C# though, so I don't know for sure if it's writable using the native APIs directly (should be, though).
It's probably perfectly OK to write your app as one big native DLL (hell, it *might* work to just change the build type from Application to Library, then rename main() or something like that). You will need to expose the library to COM, but that's easy. You can then write a very simple C#/Silverlight app (see Heathcliff's instructions, or just post the COM interface and soembody could write it for you). All the C# app needs to do is use ComBridge to access the native DLL, and call a "run()" function or something similarly simple.
For what it's worth, C# is very close to a superset of C++, at least on the desktop. The phone version is crippled a little by not allowing the use of pointers - everything has to be done with strongly-typed references instead, which can make network code a little annoying but is otherwise rarely a problem - but with a little experimentation you may find your disdain for C# to be misguided. It's a useful language to know it today's job market, if nothing else.
Why is your phone still on 7004? That's the launch retail build, something like eight months out of date. On the plus side, this means that things like ChevronWP7 Unlocker still work for you, as you found. On the minu side, it means you're putting up with bugs and missing features that you needn't be. Have you tried updating at all? If/when you do update, make sure to back up the restore points that the Zune software generates (they got in %localappdata%\Microsoft\Windows Phone Update\). That way, if you ever need to roll back to 7004, you can do it. Normally, only the most recent restore point is kept.
Flashing ROMs is safe so long as you don't try something like flashing the wrong one for your device. Unless your bootloader is unlocked (only possible on HTC), you can only flash official ROMs anyhow, which saves you from most of the risks. On the other hand, you're already on as old a ROM as you will find, and so long as you keep your restore points, you can return to it any time you want to, easily.
I'm googling now the board to find NativeIO and that webserver app. So far only references to it, but no src code.
I'm ok with isolated read/write access. All I care is persistent fs storage.
My phone is still 7004 because I just bought it so I can do some WP7 development. I don't want to mess up with updates at the moment.
As I understand from another post ComBridge is C#->COM->native c++ dll or any other dll that can be used, right? I'm just learning some COM to learn enough to start actually programming for the phone. I see that I can pass whatever data I want, but I don't seem to be able to see a way to register callbacks so that native/COM could call back to C#
mtlgui said:
I'm googling now the board to find NativeIO and that webserver app. So far only references to it, but no src code.
I'm ok with isolated read/write access. All I care is persistent fs storage.
My phone is still 7004 because I just bought it so I can do some WP7 development. I don't want to mess up with updates at the moment.
As I understand from another post ComBridge is C#->COM->native c++ dll or any other dll that can be used, right? I'm just learning some COM to learn enough to start actually programming for the phone. I see that I can pass whatever data I want, but I don't seem to be able to see a way to register callbacks so that native/COM could call back to C#
Click to expand...
Click to collapse
Basic introduction to native code and COM, including references to more background info: http://forum.xda-developers.com/showthread.php?t=1299134.
Callback from C++ -> COM -> C# can be done. Decompile the WP7 Acrobat Reader app. You'll see how it works.
Ciao,
Heathcliff74
Related
Hey guys,
There has been a lot of great strides here in learning more about this WP7 and what it's capabilities are! I'm very excited about what everyone is doing!
I'm sure a lot of you have been doing your own tinkering and was hoping to combine some efforts and maybe eventually come up with a solid SDK for home brew applications.
Here is where I'm at with my exploration:
With the COM bridge and Visual Studio 2008 one can develop a native ARM COM DLL to talk to native code from Silverlight.
I believe the ComBridge.RegisterComDll does not really register the COM class in the system registry. I believe the runtime simply caches the clsid and filename and creates the class when the runtime is looking to instantiate the ComImport COM class.
We are able to use wince's win32 API to make operating system calls from the C++ code.
There does not seem to be any security restrictions that I have come across in using the operating system from native code. I will note that without the NETWORKING caps in the manifest, DNS would only resolve cached addresses, but the rest of the sockets worked fine. I do not believe this to be a security measure, but more of a missing initialization method I am not aware of.
We can return other COM interfaces created in our native code and talk to it by implementing the COM interop interfaces in C# ( InterfaceType(ComInterfaceType.InterfaceIsIUnknown))
Currently I have written a sockets library here: dl[dot]dropbox[dot][c][o][m]/u/4165054/PhoneNetworkingSample[dot]zip
I also have the workings of a file system library that I have not completed yet. I realize there is some OEM lib out there that does FS access, but I believe it to be important to homebrew that we make our own.
I recently have been looking into Direct3D 11 API support for the phone. I have successfully created a D3D11 device and passed it back to .NET code where I was able to execute some methods on it. A lot of work needs to be done here. First the device is almost useless if we cannot render to something. I believe I have been able to create a window, but not been able to actually show it. My next method of attack will be to find the hwnd Silverlight is rendering to, hook its WndProc and do our own rendering here.
If anyone else has any information on their hacking, please let us know! You can contact me on this board or on twitter [at-sign]jmorrill.
-Jer
Great work! I will definitely have a look at the sockets source code. This should open up a lot of possibilities for app developers
Sent from my HTC HD2 using XDA App
jmorrill said:
Hey guys,
[*]We are able to use wince's win32 API to make operating system calls from the C++ code.
[*]There does not seem to be any security restrictions that I have come across in using the operating system from native code. I will note that without the NETWORKING caps in the manifest, DNS would only resolve cached addresses, but the rest of the sockets worked fine. I do not believe this to be a security measure, but more of a missing initialization method I am not aware of.
[/LIST]
Click to expand...
Click to collapse
There definitely are security restrictions applied to the native code. This is what I think. Our applications are deployed in the Least Privilidged chamber (LPC) which has dynamic capabilities by the ones we specify when the application is deployed.
<Macro Id="LEAST_PRIVILEGE_CHAMBER_GROUP_NAME" Description="Least Privilege Chamber Group" Value="S-1-5-112-0-0X80" />
and are members of the:
<Account Id="S-1-5-112-0-0X70" Description="All public capability accounts are members of this group" FriendlyName="Public capabilities group" Type="Group" />
There are certain win32 API calls which are allowed but anything which could be used to compromise the OS is only allowed to be called from the TCB chamber.
<Macro Id="SYSTEM_CHAMBER_GROUP_NAME" Description="TCB Chamber Group" Value="S-1-5-112-0-0X00" />
<Macro Id="SYSTEM_USER_NAME" Description="TCB user SID" Value="S-1-5-112-0-0-1" />
For example, loading nativeinstallerhost.exe:
<Rule PriorityCategoryId="PRIORITY_HIGH" ResourceIri="/LOADERVERIFIER/ACCOUNT/(+)/ACCOUNT_CAN_LAUNCH/NONE/NONE/PRIMARY/WINDOWS/NATIVEINSTALLERHOST.EXE" SpeakerAcc ountId="S-1-5-112-0-0-1" Description="Only TCB can launch into this chamber">
I am guessing the LOADVERIFIER is doing this using the code signing certificates. If you check your apps they will be signed with a LPC certificate but if you look ones included in the ROM then they have TCB signing.
I can't see anything that would prevent you from doing socket stuff in the security policy (as you have found). However, it looks like you need:
<Macro Id="ELEVATED_RIGHTS_RESOURCE_GROUP_NAME" Description="Elevated Rights Resource Group SID" Value="S-1-5-112-0-0X14" />
To use raw sockets:
<Rule PriorityCategoryId="PRIORITY_STANDARD" ResourceIri="/RESOURCES/GLOBAL/WINSOCK/RAWSOCKET" SpeakerAccountId="S-1-5-112-0-0-1" Description="Acess to Winsock Ra w sockets">
<Authorize>
<!-- Match loaded from:
<Match AccountId="S-1-5-112-0-0X14" AuthorizationIds="GENERIC_ALL" />
</Authorize>
Would be useful to confirm that this is the case and that this policy is actually being applied
Yep, that reflects the same behavior in Windows on the desktop. Normal socket use is okay, raw requires admin.
Do we have a tutorial on how to create native COM classes?
Also, this url explains why you cannot copy/read some files from the \Windows directory, but can LoadLibrary on them (which is how I load d3d11.dll).
blogs.msdn.com/b/windowsmobile/archive/2007/12/29/why-can-t-i-copy-programs-out-of-windows.aspx
Sorry no tutorial on making COM objects. But basically just create a new smart device mfc dll in VS2008, then add a new ATL class to the project. I modified the COM interface/classes to inherit from IUnknown vs. IDispatch.
I guess I misspoke about the security restrictions. Really what I'm looking for, is to have about the same level of access to the device as any Windows Mobile application has, which is enough to suite most of my needs personally.
Ok, I've just created a native dll and call it from Silverlight.
Once you know what type of project to create it's quite easy. The longest part was to reinstall Visual Studio 2008.
Quick question: how do you handle passing string between native and managed? I have several ways in mid but they all seems very complicated.
(nico) said:
Ok, I've just created a native dll and call it from Silverlight.
Once you know what type of project to create it's quite easy. The longest part was to reinstall Visual Studio 2008.
Quick question: how do you handle passing string between native and managed? I have several ways in mid but they all seems very complicated.
Click to expand...
Click to collapse
Depends. Sometimes you can get away with StringBuilder. Or you can do a string outgument, and create the wchar_t in native code.
What I've done so far is creating wchar_t in native code, return an IntPtr to managed code, use Microsoft.Phone.InteropServices.Marshal.PtrToStringUni to get a string and then call a custom native method to delete my wchar_t array (didn't find a release method).
Seems a lot of work just to get a string...
(nico) said:
What I've done so far is creating wchar_t in native code, return an IntPtr to managed code, use Microsoft.Phone.InteropServices.Marshal.PtrToStringUni to get a string and then call a custom native method to delete my wchar_t array (didn't find a release method).
Seems a lot of work just to get a string...
Click to expand...
Click to collapse
Just stick it in a function, and be done with it. That way you only have to do it once. Don't worry about efficiency; unless it is in a tight loop, the string conversion isn't going to slow you down noticeably.
BTW, I got registry working and started working on a registry viewer.
However, I got access denied when trying to browser most of the node.
For example I can browse HKLM\System\State but not HKLM\System.
(nico) said:
What I've done so far is creating wchar_t in native code, return an IntPtr to managed code, use Microsoft.Phone.InteropServices.Marshal.PtrToStringUni to get a string and then call a custom native method to delete my wchar_t array (didn't find a release method).
Seems a lot of work just to get a string...
Click to expand...
Click to collapse
That isn't necessary at all. Simply define your managed class/interface with the MarshalAs attribute on your params. .NET will take care of the rest.
For example:
HRESULT MyFunction([in] LPWSTR param)
Would translate to:
UInt32 MyFunction(
[MarshalAs(UnmanagedType.LPWStr)]
[In] String param);
Thanks Rafael.
This is nice! How do I do the opposite? I need to create a string in unmanaged and use it from managed code Do I just have to use [out] instead of [in] in your example?
This is much simpler that my method
(nico) said:
Thanks Rafael.
This is nice! How do I do the opposite? I need to create a string in unmanaged and use it from managed code Do I just have to use [out] instead of [in] in your example?
Click to expand...
Click to collapse
Yep, it should match the direction indicated in your COM library's IDL. It basically just drives how Marshaller handles copying of memory, pinning, etc.
You guys are smarter the me at this, obviously, but is there a site where you share your code? because i'm smart enough to use existing code and make something happen..
jmorrill said:
I recently have been looking into Direct3D 11 API support for the phone. I have successfully created a D3D11 device and passed it back to .NET code where I was able to execute some methods on it. A lot of work needs to be done here. First the device is almost useless if we cannot render to something. I believe I have been able to create a window, but not been able to actually show it. My next method of attack will be to find the hwnd Silverlight is rendering to, hook its WndProc and do our own rendering here.
Click to expand...
Click to collapse
Have you checked out ZuneBoards? They've done some work in this area already with their OpenZDK, which looks similar to what we may need to do. Their method of breaking out of the CLI virtual machine is different than ours, but a lot of what they've done is what we want to do, too.
One thing that doesn't work are the typical WinCE graphics functions:
GetDC(NULL) ;
GetDesktopWindow();
LineTo();
GetClientRect();
That is they work, but the root window is empty! 0 wide and 0 tall. The drawing engine (unsurprisingly) is elsewhere.
ajhvdb said:
You guys are smarter the me at this, obviously, but is there a site where you share your code? because i'm smart enough to use existing code and make something happen..
Click to expand...
Click to collapse
Have you gotten anything to compile yet?
Check this one out: http://dl.dropbox.com/u/4165054/PhoneNetworkingSample.zip
And see if you can get it to compile (I would make it an attachment in this post but it's jmmorril's code). I've been using Visual Studio 2008 and the WinCE 6 refresh to compile the com dll: http://www.microsoft.com/downloads/...3A-A651-4745-88EF-3D48091A390B&displaylang=en
Then I copy the com dll over to my visual studio 2010 Windows Phone project, ready to be used. There are probably better ways, but you need to find out at least some way of doing it.
I've managed to create a basic Registry Viewer, readonly for the moment.
For now, I didn't manage to get access to root path, so the first 2 levels are hardcoded.
Download it here: (link removed, see below)
Edit:
Updated version here: http://bit.ly/eEZ0Uf
(nico) said:
I've managed to create a basic Registry Viewer, readonly for the moment.
For now, I didn't manage to get access to root path, so the first 2 levels are hardcoded.
Download it here: http://bit.ly/hOWLnI
Click to expand...
Click to collapse
wow man nice work , could you also make a file explorer ?
edit: here is a direct link http://www.xda-developers.ch/download/?a=d&i=7061084002
At the moment I'm working on an app called "WP7 Root Tools". I got the registry editor almost finished, but I am also going to add a File Explorer, Certificate Stores and maybe more. When the registry editor is working I will release the first alplha-version. As the title of the app implies, the tool uses root privileges to perform queries and transactions. I let the tools parasitize other processes to get the code executed in the TCB chamber of the device. I have this working stable now on my Samsung Omnia 7. Unfortunately I have to use a little bit of device-specific API's to do this. And I have to make quite a detour to make it work, which has a negative impact on the performance.
So the ultimate goal is that, in the end, this will work with other, more direct API's, which work on all devices. During my research I found some possiblities that need more investagation. I already decided that I will first concentrate on getting this working with my Samsung device, so that I have at least the tools to do further research. But I thought I'd drop some of my findings here that may lead to better device-support and better performance for future-versions of the tools.
There are many ways that may lead to executing code with elevated or root privileges. But in this post I want to concentrate on XML provisioning. A lot of info can be queried and configured through these API's. I have tried to call the native OS functions for XML provisioning. The function you need to call is: DMProcessConfigXML(). And it is declared in: Cfgmgrapi.h. If you call this function it returns errorcode: 0x4ec (or 0x800704ec), which means "Access disabled by policy". If you use a native COM dll and you forget to add ID_CAP_INTEROPSERVICES to the WMAppManifest.xml, you will get the same errorcode when calling a native function through the COM-interop. So when I get the same errorcode when calling DMProcessConfigXML() this may suggest, that I might be missing a capability in the WMAppManifest.xml.
In another thread on this forum some undocumented capabilities were discussed. One of them was ID_CAP_WAP. Since OMA Client Provisioning is also call WAP-Provisioning, I thought that might be the missing capability. I was not able to add the capability from within Visual Studio, because the capability is missing from the corresponding xsd's so it will give an validation error on building the project. But I could add it manually after the project was build. When I deploy it to the device, using the Application Deployment tool, it would return "Access is denied". I thought it might be an invalid capability, but when I changed the capability to ID_CAP_XXXXXX that would return "Install failed. Fix the capabilities." which is the real error message for an invalid. That implies that ID_CAP_WAP is in fact an existing capability, but I'm just not allowed to use it. When I would be able to use it, I would probably have access to the function DMProcessConfigXML(). That part of the app would be impesonated into higher chambers.
So the big question is what is keeping me from using the ID_CAP_WAP? Why am I not allowed to use it? I tried to attach a debugger to XapDeploy.exe, but it does not throw any exceptions at all. The errorcode is generated in the phone. Getting this fixed will give a big boost to getting closer to root access on all devices. Any help or insight on this will be appreciated.
Heathcliff74
I sent some tweets to da_g, chris, chevron, julien schapman, and a few other devs to let them know this is going on...I'll try tom hounsell too he may know a bit more about this
I'm notifying notebookgrail too because he has been doing some work with dell venue pro devices
Good luck
At a wild guess, it's probably looking for a signature. Using signed code for trusted functions is the kind of thing MS likes to do. :-/
All that said, if you have ProvXML working on Samsung, I would *love* to take a look at it. I'm maintaining a cross-platform Homebrew library. Currently I have at least partial ProvisionXML on HTC and LG, but none on Samsung. I don't have a Samsung device to test with, which is making it hard to try things out...
ID_CAP_WAP isn't a capability you can assign yourself. A higher up has to assign it to you.
<!-- Account loaded from: W:\WINCEROOT\temp\oakcopy28570\Release\x86\XDE\Policy\cb659c75-eac9-4db7-afd8-055632acf233.policy.xml(292,2) -->
<Account Id="S-1-5-112-0-0X71-0X49445F4341505F574150" Description="Autogenerated group for capability ID_CAP_WAP" FriendlyName="ID_CAP_WAProvides access to WAP API" Type="Group">
<!-- MemberOfGroup loaded from: W:\WINCEROOT\temp\oakcopy28570\Release\x86\XDE\Policy\cb659c75-eac9-4db7-afd8-055632acf233.policy.xml(293,2) -->
<MemberOfGroup GroupAccountId="S-1-5-112-0-0X71" />
Click to expand...
Click to collapse
(BasePolicy.xml)
domineus said:
I sent some tweets
Click to expand...
Click to collapse
Thanks.
GoodDayToDie said:
All that said, if you have ProvXML working on Samsung, I would *love* to take a look at it.
Click to expand...
Click to collapse
Well, the whole ProvXml stuff will become irrelevant, when I finish the tools. Because ProvXml is not really user-friendly and my tools will provide that functionality in a user-friendly fashion. So at this moment I want to concentrate on finishing the first alpha-version. Later on, I will probably clean-up the code and release it. But it's quite complex, because I added async multithreading to keep it all smooth.
WithinRafael said:
ID_CAP_WAP isn't a capability you can assign yourself. A higher up has to assign it to you.
Click to expand...
Click to collapse
Thanks for this info. But what I read from this is that you just need to be able to impersonate. Has anyone tried CeImpersonateToken() with this SID?
Abstraction of the ProvXml capabilities is awesome, assuming that we can fully use them and/or extend them if needed. It's useful for a ton of stuff. I've written a small amount of abstraction for registry writes and such, but having the full functionality exposed through a clean API would be fantastic.
As it is known that HTCUtility.dll will provide complete, unrestricted access to the TCB chamber on HTC devices, can this be used to unlock (at any level) the OS?
I have not heard anyone speaking of it and exists on my HTC Arrive. Seems to be a bypass for unrestricted access to anything within HTC devices.
I am looking at it myself, but thought I would share.
See details here...
http://labs.mwrinfosecurity.com/files/Advisories/mwri_htc-htcutility-kernmem_2011-11-10.pdf
Your link is down
very interesting but you link is down so please fix it so I can take a look. I too have a HTC arrive and have been working on an unlock.
Don't know what happened to the link.
Here is the link to the google docs version.
https://docs.google.com/viewer?a=v&...1C1HkN&sig=AHIEtbTwK-r8RyAyFmt1ai119m7EVAqsNA
-Paul
This looks promising, I'd like to know if what's written there is true ...
The paper is a couple months old, so it *could* have been patched by HTC... but hey, it also might not have been! This bears investigation post-haste.
It's easy enough to use this to execute some arbitrary code at high permissions, which is certainly useful as-is (do things like unrestricted registry and filesystem access). The real potential of it, though, is to turn off the security restrictions for specific apps. Essentially, get the benefits of a "fully unlocked" ROM but on a stock ROM, and only for the apps you specify.
One thing to note here: this is still going to require an interop-unlocked phone. It's opening a handle to a driver, and just like everything else that does so, it needs ID_CAP_INTEROPSERVICES. This is great news for owners of interop-unlocked/unlockabe phones (since this makes interop-unlock useful again) but probably doesn't help on 2nd-gen phones or on the Arrive (unless you want to roll back to NoDo, in which case this can probably be used to make an interop-unlock that works on Mango, though it wouldn't be easy).
I hope some one gets this working for the Arrive ASAP
Oh this was talked about a while back. It was patched back in NODO
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
GoodDayToDie said:
I'll try it out in any case, and report back.
Click to expand...
Click to collapse
Thank you
GoodDayToDie said:
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
Click to expand...
Click to collapse
Yeah I think it was mentioned here on XDA and it was believed to already have been patched.
I think by "patch" they mean that Interop was restricted as of Mango, thereby securing this exploit, in Mango. But for those that are Interop unlocked, this should still grant full access to everything else.
Just my observations. I have an Arrive and am not Interop unlocked yet, so I can't test it.
Looking at the hand-free provisioning to see if I can find a way to leverage that....
-Paul
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
All the information looks like it is in the advisory. KDataStruct is what you want. That is equivalent to the PEB in Windows CE.
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
Can you confirm this works only on already Interop Unlocked device ?
Thx for your efforts.
Could htclv.dll be helpful in setting security on an app? It supports the following functions:
LVModInitialize LVModUninitialize LVModAuthenticateFile LVModRouting LVModAuthorize LVModGetPageHashData LVModCloseAuthenticationHandle LVModGetHash LVModProvisionSecurityForApplication LVModDeprovisionSecurityForApplication LVModGetSignerCertificateThumbprint LVModSetDeveloperUnlockState LVModAuthorizeVolatileCertificate LVModGetDeveloperUnlockState
In particular the "Deprovision Security for App" and "Get/set DeveloperUnlock" or maybe "Authorize Volatile Certificate"....
Or maybe htcpl.dll which seems to be the HTC policy engine interface. Supports:
GetFunctionTable PolicyCloseHandle PolicyEngineInit PolicyRuleAbortTransaction PolicyRuleAddRawData PolicyRuleBeginTransaction PolicyRuleBuildRawData PolicyRuleCommit PolicyRuleCommitTransaction PolicyRuleCreate PolicyRuleDelete PolicyRuleFindFirst PolicyRuleFindNext PolicyRuleGetInfo PolicyRuleOpen PolicyRuleParseRawData PolicyRuleReadRawData
These all look good to modify the security policies on HTC, assuming Interop-Unlocked.
-Paul
@dragonide: Confirmed, this requires interop-unlock since the very first step is opening a handle to a driver.
@Paul_Hammons: The LVMod functions look quite interesting indeed. Where are you getting these functions from (straight out of the DLLs, or some doc somewhere, or decompiled code, or...?), are they user or kernel entry points, and what permissions do they require? The ability to modify app security doesn't do as much good if you already have to be high-privileged to call it, though it might simplify my current goal.
@n0psl3d: Cool, I'll get to work on it.
@n0psl3d: KDataStruct contains kernel information, but I'm pretty sure what I need is in a PROCESS struct (such as is pointed to by pCurPrc). The problem is, I can't find any documentation for that struct. I'm searching online but so far coming up empty. CE doesn't seem to use PEBs or TEBs as I've seen them on NT (not terribly surprising, but annoying).
EDIT: I'm downloading the Embedded CE toolkit, which comes with source code. It'll take a while but hopefully that will have what I need.
OK, digging through the CE source I've found some interesting things. No idea if this will work yet; it'll be exciting just to make it compile.
PROCESS struct -> hTok (handle to a Token) -> phd (PHDATA, pointer to the handle data) -> pvObj (PVOID to the actual object, which is probably a TOKENINFO) -> psi (pointer to ADBI_SECURITY_INFO) -> contains the actual ACLs and privileges, and can be created from an account ID.
Probably the easiest option is to find a relatively high-privilege process and clone its token or some such. Token re-use (if I increment the reference count, this should work) may be easier. Modifying an existing token might also be doable.
Anyhow, I'm not going to have this finished tonight, but it'll get there. For those wondering wht you can do with this, it basically breaks you out of the sandbox entirely. You can call any function, access any resource, etc. that is available to a userland process (executing in kernel mode is also possible but trickier). Practically speaking, this makes all the other high-privilege COM DLLs useless - instead of ComFileRW, just use the file IO methods (anywhere you want), instead of DMXMLCOM just call ConfigProvXml directly. Even things like launching native EXEs directly should become possible (run those Opera ports on a stock ROM, for example).
I'm sorry, I still don't know what any of that means. But it sounds good! I wish I knew how to do this kind of stuff. Thanks for all of your work!
I'm posting this here because it says I need to get 10 posts in order to post on the Windows 8 development forums.
Why does the Windows RT jailbreak require that you press the volume button? As far as I can tell, pressing volume is used to trigger a code path in winsrv.dll on which a hook is placed. The hook jumps to the code cave between the .text and .data segments.
Reading the disassembly, the injected code uses the native API equivalent of EnumDeviceDrivers to get ntoskrnl.exe's base address, then calls the broken NtUserSetInformationThread subfunction 9 0x7EFF0 times to clear g_ciEnabled in the kernel. (I read the part about interlocked operations causing an exception in ARM if the target is unaligned, unlike x86 where it's merely not atomic.)
Instead of hooking an existing code path, why not inject a DLL into csrss.exe and create a thread in it? This seems like it would be much more stable, and wouldn't require pressing the volume button. CreateRemoteThread doesn't work with csrss.exe, because it tries to register the new thread with csrss.exe. Oops. However, RtlCreateUserThread *does* work, since native threads don't need to talk to csrss.
Where did cdb.exe come from? It doesn't come with the Visual Studio 2012 Remote Tools, so I'm guessing that it's a leak. In the absence of any other information, I'm going to guess that it's a leaked ARM version of Debugging Tools for Windows given to hardware developers who write drivers for Windows RT.
I'm working on a custom jailbreak that improves on a lot of issues. It's a single file, a .bat, that extracts everything needed, and a jailbreak program written in C. I've already gotten the custom C DLL loaded and executing, and am now looking into what I need to do to csrss.exe. Getting code executing inside csrss.exe won't be too hard, but I'm wondering what that code will need to do.
Moved here as not an Android related development issue, so was out of place in General forums.
You won't be able to inject .dll's. Windows will refuse to load the modules, unless the jailbreak has already ran.
As far as why it needs the volume button, you're correct in that it just executes an easily hooked code path in csrss.
netham45 said:
You won't be able to inject .dll's. Windows will refuse to load the modules, unless the jailbreak has already ran.
As far as why it needs the volume button, you're correct in that it just executes an easily hooked code path in csrss.
Click to expand...
Click to collapse
My DLL was linked with /filealign:4096, resulting in a perfect RVA to file offset mapping (assuming I don't create more than a small amount of zero-initialized global variables). With that, I can use NtMapViewOfSection without SEC_IMAGE to map it into csrss's memory without ci.dll getting in the way.
Once the DLL is mapped, I fix up its relocations, load the imports, and RtlAddFunctionTable. From there, the DLL is stable enough to do most things. All this works already - I'm just writing what to do next.
Does Tuesday's win32k.sys patch fix this bug? I saw that the patch had fixes for like 20 win32k bugs found by the Google guy who discovered the NtUserSetInformationThread 9 exploit.
Myriachan said:
I'm posting this here because it says I need to get 10 posts in order to post on the Windows 8 development forums.
Why does the Windows RT jailbreak require that you press the volume button? As far as I can tell, pressing volume is used to trigger a code path in winsrv.dll on which a hook is placed. The hook jumps to the code cave between the .text and .data segments.
Reading the disassembly, the injected code uses the native API equivalent of EnumDeviceDrivers to get ntoskrnl.exe's base address, then calls the broken NtUserSetInformationThread subfunction 9 0x7EFF0 times to clear g_ciEnabled in the kernel. (I read the part about interlocked operations causing an exception in ARM if the target is unaligned, unlike x86 where it's merely not atomic.)
Instead of hooking an existing code path, why not inject a DLL into csrss.exe and create a thread in it? This seems like it would be much more stable, and wouldn't require pressing the volume button. CreateRemoteThread doesn't work with csrss.exe, because it tries to register the new thread with csrss.exe. Oops. However, RtlCreateUserThread *does* work, since native threads don't need to talk to csrss.
Where did cdb.exe come from? It doesn't come with the Visual Studio 2012 Remote Tools, so I'm guessing that it's a leak. In the absence of any other information, I'm going to guess that it's a leaked ARM version of Debugging Tools for Windows given to hardware developers who write drivers for Windows RT.
I'm working on a custom jailbreak that improves on a lot of issues. It's a single file, a .bat, that extracts everything needed, and a jailbreak program written in C. I've already gotten the custom C DLL loaded and executing, and am now looking into what I need to do to csrss.exe. Getting code executing inside csrss.exe won't be too hard, but I'm wondering what that code will need to do.
Click to expand...
Click to collapse
Hello!
Glad to see here sensible Guru, who understand, that non-permanent JB, requiring "Vol -" pressing and hanging in RAM - is a vicious way! I can't understand reluctance of Netham45 to make a permanent JB (nothing personal). If you will develop your own JB with options, described above, it will be a breakthrough! Wish you good luck and fastest implementation of planned :fingers-crossed:
If you think netham45 is reluctant to make a permanent jailbreak, your lack of understanding is far greater than you know. A permanent jailbreak would be excellent, especially one that was active immediately at boot (instead of requiring a delay after booting, during which time the default restrictions are still in place).
However, there are some issues with the current jailbreak technique. In particular, it's dependent upon knowing the correct offset for the flag that needs changing, there's no way to know for certain the state of that flag before writing it, and the offset changes with updates. If the wrong offset is written to, or the wrong value written, the system crashes. Therefore, making a "permanent" jailbreak using this hack runs a very real and serious risk of putting the device into a bluescreen-reboot loop after an update, even one that isn't intended to break the jailbreak, just by accident.
In order to make a reasonably safe permanent jailbreak, a new jailbreak method will need to be discovered. That's not a trivial thing; the first one took some time to discover at all, and the effort on finding new methods has fallen off somewhat as many people are now looking for ways to use the existing one rather than looking for new ones. Additionally, even if a new method is found (which would be good; we should always have a backup), there's no guarantee that the new technique will any better-suited for being persistent or even automatic on bootup.
GoodDayToDie said:
However, there are some issues with the current jailbreak technique. In particular, it's dependent upon knowing the correct offset for the flag that needs changing, there's no way to know for certain the state of that flag before writing it, and the offset changes with updates. If the wrong offset is written to, or the wrong value written, the system crashes. Therefore, making a "permanent" jailbreak using this hack runs a very real and serious risk of putting the device into a bluescreen-reboot loop after an update, even one that isn't intended to break the jailbreak, just by accident.
Click to expand...
Click to collapse
I did put in some code to automatically find the offset (downloads the pdbs from MS and disassembles that chunk of code from ntoskrnl and parses it), though it still does make some heavy assumptions that I wish I could do without. It should be in 1.13a.
Note that it's still just assuming that csrss is perfect, though.
Denis_63 said:
Hello!
Glad to see here sensible Guru, who understand, that non-permanent JB, requiring "Vol -" pressing and hanging in RAM - is a vicious way! I can't understand reluctance of Netham45 to make a permanent JB (nothing personal). If you will develop your own JB with options, described above, it will be a breakthrough! Wish you good luck and fastest implementation of planned :fingers-crossed:
Click to expand...
Click to collapse
I'd love a persistent jailbreak, but we don't have an exploit for one yet. I'm not reluctant to make one, I don't presently have the ability to. The tool that Myriachan is talking about would have the same issue.
netham45
GoodDayToDie
Hey, guys, I bag pardon, if I were too harsh... I'm not the Guru as you are, and really had no notion about the level of complexity of the problem. Becose of that I wrote - "Nothing personal" Wish all of you GOOD LUCK in your important work!
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.