Develop Bugs

[APP] Resident Mort - Scary Good, not Scary Evil

*Anyone get the reference? Haha*
Resident Mort
The Scripter's Companion​
Current News / Status:
Resident Mort is currently Under Development
Resident Mort is planned to be a background EXE that will extend the functionality of MortScript available to developers through the usage of the "PostMessage" function.
Resident Mort is planned to extend functionality by adding extra, possibly more complex, functions or even adding in the ability for more complex GUIs.
Features (Green = Implemented, Blue = In Testing, Orange = Planned, Red = Failed):
GetProcessList - Gets a list of Running Programs
GetRecentApps - Gets a list of Recent Apps (10)
CreateScript - Creates a MortScript with the provided info
MakeFile - Makes a file of any kind with the provided info
MakeFolder - Makes a folder at the specified location
RegToEvent - Registers a File to an event​
UnRegFromEvent - Unregisters a File from an event
IsIdEventRegistered - Checks to see if a File is registered to an event.
DispImg - Displays an Image to the screen [and gets where the user Presses]
MakeForm - The Initial call for setting up an 'advanced GUI' form
FormAddObject -A Call that will add one of the predefined objects to the form being created
DeployForm - The Final call for setting up an 'advanced GUI' form, displays it to the user
This application is being made for MortScripters, to possibly make some projects easier. Since I don't use MortScript so much any more, I do rely on you the developers who use MortScript, to tell me what you want in the program.
Since I have a good deal of Functions there, I will commence work on a primary release

Saved For Future Use - Features and Screenshots

like the idea! advanced guis would be very useful

so this is a compiler? I am not sure what this is about
-sorry

No, this is a Resident App, an EXE that is always running in the background. It will have certain functions in it which can be accessed by MortScripters.
All the functions can be called with PostMessage ( I will provide documentation on how to do so, when I make a first release ). Then the results will either be written in the REGISTRY, written to a FILE, or copied to the CLIPBOARD (depending on how the scripter wants to handle the task).
Does this clarify it a bit?

Thanks for sharing!

A small update:
I am using this 'decent' planning utility, to help me keep track of my growing projects. According to this utility, the program is close to 30% complete. Then again, this is just a 'decent' utility haha. I would say, in my estimation (since some Code is "Copy + Paste"), I am close to 60% to 75% done.
A small change in my plans:
While I originally had the intentions of making this program as simple as a PostMessage in MortScript, I found out the following two Limitations:
1) MortScript's PostMessage/SendMessage only support(s) sending Numbers in the wParam and lParam parameters...very disheartening.
2) Due to #1, I made an assistant EXE, which would be run instead of calling PostMessage [this way I could do it Natively in my own control], but it is MUCH harder to transfer data between two applications that I would have thought! Due to Virtual Stacks and Memory Allocation 'rules', I couldn't EASILY do this.
So Here is my change:
In order to use Resident Mort, scripters will have to do about 3 or 4 commands to run. The only real commands that need to be used are PostMessage and RegWriteString (Did I get those right?).
In any case, my Resident Mort will read the Registry for corresponding wParam and lParam values and use those [in the future I will attempt Clipboard integration, to avoid Registry Interfacing].
When I release this program to the public, I will try to include a MortScript file that shows how to use all the functions. I don't remember much of MortScript [unfortunately], but I was thinking it could be helpful to make a "Library" of MortScript functions so a script will only have to call that function. But that is if some kind dev. would like to help out later on
Anyways, Thats that for this update. Expect a result in the coming week.

That sounds interesting for adv. gui functions.

Cyclonezephyrxz7 said:
1) MortScript's PostMessage/SendMessage only support(s) sending Numbers in the wParam and lParam parameters...very disheartening.
Click to expand...
Click to collapse
That's not MortScript's fault, it is design of whole Windows CE kernel, more here
I'd go with background EXE, that would listen to messages WM_USER+somenumber, maybe even region (for different actions, so you'd have both lParam and wParam free for another parameters). If you need help with this part, drop me PM on MSN, I had to study this a bit in the PinchToZoom project myself.

@OndraSter : Yeah, I know that Windows CE has limitations, however it is not impossible. Such an ability could be implemented in a code-update to MortScript. I did my reseach (if you look at #2, I mention that I found it much harder to transfer data between exe's that I had hoped) and found that you can transfer data via SendMessage (the Synchronous method) using a TRANSFERDATASTRUCT and WM_COPYDATA. If MortScripts interpreter could identify a SendMessage with a String value in either wParam or lParam, then it would create such a structure and transfer it, the receiving app would HAVE to take care of deleting the data though, or you have mis-used RAM.
As for how it is going to work now, I did not consider using WM_USER + a value, mainly because my program won't be using other Messages, and will only act if the correct wParam/lParam are provided (preventing accidental execution if the System decides to post a message with the same ID). I have it mostly covered, and I am closing in on finishing (currently with Reg data retrieval only, no Clipboard yet). I have completed 3 of the 7 Proposed Functions (MakeFile, MakeFolder, CreateScript) and I would have finished RegToEvents, but I got sorta lazy hehe. DispImg shouldn't take me more than a few minutes when I get to it, and once I get the API calls for Processes and figure out how to read the MRU reg-entry, I will have the last 3 complete!
As for Clipboard data retrieval, unless I am using the entirely wrong API calls, MortScript has an interesting way of using the Clipboard...I tried copying simple strings like "hello world" to the clipboard using MortScript, then trying to retrieve them in my Resident Mort, but the clipboard always comes up empty... Any ideas anyone?
Thats that for now I am about ready to release....any other functions you want implemented?

As for how it is going to work now, I did not consider using WM_USER + a value, mainly because my program won't be using other Messages, and will only act if the correct wParam/lParam are provided (preventing accidental execution if the System decides to post a message with the same ID).
Click to expand...
Click to collapse
http://msdn.microsoft.com/en-us/library/ms644947(v=VS.85).aspx

Good idea, the only downside being that it will generate the Message Numbers each time it is run... It is not assured that the Post / Send Message MsgIDs will remain constant.
Thanks for the link however

Cyclone,
Sorry about taking so long to post here...
How about, when the BT is on, this reports what is "out there" based on what the BT stack is telling you.
That is, it should read the surrounding area, then report that is saw my BT dongle. In the car, it should report that it saw my BT GPS unit.
Then, I can use that information to change my profile. That is, when it sees the BT dongle, regular phone calls. When it sees the BT GPS unit, run speaker mode, or connect to the GPS unit for phone calls.
Thanks!
--Ironhead
P.S. it would need to support the Touch Pro 2, Rhodium (my understanding is that it is Widcomm BT stack)

I"ll see what I can manage. I am really 'grid-locked' in my work on a couple of projects already So a release of this may have to wait a while....Sorry

I wish I had caught you a little sooner...
AutohotkeyCE may be a better base to work from than Mortscript...
http://www.autohotkey.net/~Micha/AutohotkeyCE/html/index.htm
In fact... AHKCE should be able to cater to all of your needs without the separate resident app

Yeah, I have seen that before. This project is really just a little challenge for myself to expand upon MortScript [because I know it is widely used].
Thank you for the link/suggestion however

I've been playing with Mortscripts for a while, I'm really thinking I can do everything I want, right from there...
EXCEPT:
Actually getting the information from the BT stack. I just need to see if there are any registered BT devices around my phone (so I can tell if I am in my car, at home, at work, etc.).
--Ironhead

Bumpity bump!

Hehe...Yeah, sorry for the lack of work on this. Check out FFP_LockScreen. I am working on a new release. I have very little time now, and I can't manage more than just one or two projects at a time. Once I release FFP_LS 3.0, I can devote some time MAYBE to this project. It all depends on how quickly the XDA-Marketplace idea takes off.
Sorry =\

I you can add a tool to make an GUI... it s must be soo cool...

[Q] [Resolved] [.Net CF 3.5] How do i create a treeview based file browser

I have a problem with a project i'm working on and that is:
How do i create a TreeView based file browser that can export a selected path and filename to a textbox and a Process.Start call at the same time. That's it in a nut shell. The main part if the tree view bit but i haven't figured out how to do variables yet and i'm gonna need one for the second part. I have spent hours googling and i have this question posted on a dedicated VB forum.
I'm using Visual Basic 2008 as the IDE and .Net CF 3.5 as the language (obviously)
If anyone has any ideas on this i'll gladly hear them coz i am really stuck. I found writting code to soft reset a device was easier

TreeNodeCollection tr=treeView1.Nodes;
TreeNode tn;
foreach (string dirs in System.IO.Directory.GetDirectories(System.IO.Directory.GetDirectoryRoot(Assembly.GetExecutingAssembly().GetModules()[0].FullyQualifiedName)))
{
tn = new TreeNode(dirs);
//tr = new TreeNodeCollection();
tr.Add(tn);
}

ergintiravoglu said:
TreeNodeCollection tr=treeView1.Nodes;
TreeNode tn;
foreach (string dirs in System.IO.Directory.GetDirectories(System.IO.Directory.GetDirectoryRoot(Assembly.GetExecutingAssembly().GetModules()[0].FullyQualifiedName)))
{
tn = new TreeNode(dirs);
//tr = new TreeNodeCollection();
tr.Add(tn);
}
Click to expand...
Click to collapse
Is that C# code or VB?

M3PH said:
Is that C# code or VB?
Click to expand...
Click to collapse
C#....VB don't have the curly brackets

So i've come back to this question after a few months avoiding VB. I'm now working on a new product and the lack of an folderbrowserdialog object in .Net CF is killing me.
What i need is this (oh and thanks to everyone that posted above but i can't make that solution work). A way to list all the folders on a device and then select one that can be passed to a variable so it's path can be used elsewhere. Maybe also pass the path to a textbox just so it's clear what you have selected. I've spent 2 days googling this and i did find a few things. Most don't work and the rest are in c# which is not much good. So if anyone wants to help me out i would really appreciate it.

Get your head round this.........
O.K. Here's how it's done, with a crash course in one of the most powerful of programming techniques - Recursion. It can confuse the hell out of rookie programmers, as they just can't get their heads round what's going on. It is dependant on a function's local variables and fortunately, .NET's stack based architecture allows us to use it to the full.
You will need, 1.) a TreeView object - named "treeView1" and 2.), a label named "label1" placed underneath it. The label is only there to prove the point that we can get at the full pathname of the selected directory in the Treeview. In reality it can be dropped, just put your processing code directly in the TreeView's AfterSelect() event.
The Form_Load() event gets the directories in the root directory, by calling GetDirList with an initial directory of "\".
GetDirList() adds the directories to the TreeView then calls GetDirList again on each directory to get any subdirectories, and again on each subdirectory, ad nauseum. Keep going until there are no more directories returned.
When completed TreeView contains a list of every directory/subdirectory on the device.
When you select an item from the TreeView the full pathname is displayed in the label. The image at the bottom shows it running under debug on the WinMo 5.0 emulator. There are several directories you would not normally see on your device.
Good Luck, stephj.
Code:
Private Sub Form1_Load(ByVal sender As Object, ByVal e As EventArgs)
Me.GetDirList("\")
End Sub
Private Sub GetDirList(ByVal PathName As String)
Dim dirs As String
For Each dirs In Directory.GetDirectories(PathName)
Dim tn As New TreeNode(dirs)
Me.treeView1.Nodes.Add(tn)
Me.GetDirList(tn.FullPath)
Next
End Sub
Private Sub treeView1_AfterSelect(ByVal sender As Object, ByVal e As TreeViewEventArgs)
Me.label1.Text = e.Node.FullPath
End Sub
P.S.
You will need the VB equivalent of using System.IO adding to your project.
This stuff has been around since .NET CF 1.1
The original project was written in C#, I used .NET Reflector to translate it into VB from the original. The original C# is included here:-
Code:
using System;
using System.Text;
using System.Windows.Forms;
using System.IO;
namespace Test
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
GetDirList("\\");
}
private void GetDirList(string PathName)
{
foreach (string dirs in System.IO.Directory.GetDirectories(PathName))
{
TreeNode tn = new TreeNode(dirs);
treeView1.Nodes.Add(tn);
GetDirList(tn.FullPath);
}
}
private void treeView1_AfterSelect(object sender, TreeViewEventArgs e)
{
label1.Text = e.Node.FullPath;
}
}
}

cool thanks. I'll have a look at coding this tomorrow (i having some fun time right now).
I did have a look at doing this with a list box yesterday but i was getting errors left, right and centre so i really do appreciate the help.
Just an FYI the VB equivelent of "using" is "imports" otherwise most of the objects are the same but i don't nee to worry about adding it as the program is already interacting with the file system.
Again thanks very much. I really appreciate you taking the time to help me out.

I've just had a look at implementing this but i'm having trouble getting the treeview to populate with the folder list. What am i doing wrong? the object names all match up and i can't see why it's not working. Am i just being plain dense?
What i have Is pretty much what you posted except for a few changes to allow for the fact that the treeview object is in a tabcontrol and i already have a bunch of labels knocking around so the label is called label28 and not label1.
I'm sorry if it appears like i'm not trying or i'm asking you to do all the work but i am genuinely really stuck. I get the recursion principal, That's not an issue but i'm trying to create something from scratch that should really have been included in .net CF and i'm just not that good a programmer yet

Should work..... but without seeing the actual code it's rather hard to remotely debug it.
To prove the point, here's the complete VS2008 VB .NET CF 3.5 project.
In the \bin\release directory is the actual executable. If you have .NET CF 3.5 on your device, drop DirList.exe onto it and run it.

I had a look at the project you posted and just copied the coded over. I did make some tweaks so it only loaded the folder list when the tab the treeview was on was clicked but that didn't work so i repated the code in as is and voila! it works. Now all i need is to create a variable to store the selected path in but i think i can manage that.
Again a huge thanks.

Hierarchical view......
Here's the project to indent, compress, and expand the directory tree structure.

I was just playing around with this and i noticed that when you click on a directory below "\" the path becomes "\\this\path". This is obviously not a valid windows mobile path and it is causing an IOexception and I have no idea how to fix it. Google suggests lots of c# pages that say to use a regular expression to strip out the illegal characters but the example i found was for the entire path and it seemed to check each character against a variable of illegal values. I'm sure if that would work for me. Heres the link.
Let me know what you think.

I have no idea where the \\this is coming from, I can't replicate it.
To filter out the extra leading slash use this:-
Code:
Private Sub TreeView1_AfterSelect(ByVal sender As System.Object, ByVal e As System.Windows.Forms.TreeViewEventArgs) Handles TreeView1.AfterSelect
If TreeView1.SelectedNode.FullPath.Length() = 1 Then
Label1.Text = TreeView1.SelectedNode.FullPath
Else
Label1.Text = TreeView1.SelectedNode.FullPath.Substring(1)
End If

Interesting new problem has cropped up with this code. It doesn't seem to work on rhodiums. It works fine in the emulator, my HD2 and all of CajunFlavouredBob's devices but i have a user that has a rhodium that get the error posted here. I can't replicte it and i don't have a rhodium to test it with. Any ideas?

Hmmmmm another tricky one. Without seeing the device actually throw the error, it can be a bit difficult.
Does this machine actually report the storage card as "\Storage Card"? Some machines don't. In which case you may have to use some storage card enumeration trick to get hold of the real name it uses. This may not apply in this case.
Also, to make things trickier still, the stack dump shows 'GetInternalDirectoryNames()' as the function throwing the error first. This is a level below your call of GetDirectories(), and is being used by the OS to actually go get the info. You may have to create a test version of EXCT2 full of Try...Catch programming blocks, to try to get to the real point where the error is being thrown.

well this turned out to be a memory related issue. So instead of using the folder browser we now use the stock winmo savedialog. because it uses less memory and allows us access to the locations we need.
Thanks for helping though steph.

[singularity]

[SINGULARITY] -
Singularity
Singularity (and the language of such Sing#) is a Microsoft operating system currently on codeplex as RDK 2.0 which is now core to this project - getting Sing# and Singularity to run on ARM (hd2) then can easily boot NT or anything and everything - essentially, NT will happen, but is irrelevant, as need to here first give MAGLDR an d HD2 ability to run Common Language Runtime AND Singularity (.ARM ver of .X86) -
GOAL= make ARM Singularity Kernel run on HD2 then run apps using this core as native apps or strap out onto whatever...
See update on last page of this thread.
ntonhd2 said:
Cotulla: repsonse to your question along with basic test build, just for compile practice run (check for errors), was succesfull; this is for ARM low level bootloader (ARMLDR ) which runs on ARM (hd2, ultimately here) and then grabs LDR (ntldr) then all other files (see my reply) then NTOSKRNL.EXE -> its attached for you to download on next page - thanks again for your input .
NT on ARM:
http://www.microsoft.com/presspass/press/2011/jan11/01-05SOCsupport.mspx
http://www.microsoft.com/Presspass/Features/2011/jan11/01-05SinofskySOC.mspx
http://www.bloomberg.com/news/2010-...ion-of-windows-for-arm-chips-at-ces-show.html
http://thecoffeedesk.com/news/index.php/2009/04/23/net-could-be-key-in-windows-on-arm-netbooks/
http://www.osnews.com/story/24165/Windows_NT_on_ARM_It_s_a_Server_Thing
Please also read my last post regarding Xbox running NT.
And understand I AM TALKING ABOUT NTOSKRNL with Native CLI and not running full WindowsXP or 7 or watever! .
hi xda, put this in hd2 general as could be relevant to linux or wp7 or hd2. Thinking of starting project here of pretty grand scale if people are interested. Now that a lot of work has already been done i think it will not be as hard as it may appear or sound at first.
I am thinking about using new wp7 bldr +- oal +- nk.exe to set up emulation of bios expected on pc then trying to jump to 2003 server equiv ntoskrnl.exe. (and then probably just a native command line interface like alex ionescu tinykrnl project back in the day, a ncli for nt with usb keyboard and not much more to start with: Further dev much later).
Nk will handle underlying lack of pci, bios, ints, and addresses, (+is firmware) but actual switching to nt kernel is for real after that: To build a strapping kernel with ce7/wp7 architecture and initial drivers that goes on to then launch full nt kernel.
Yeah - i have \nt\private\ntos\ source code and no it is not the normal nt4 or other w2k leak- it is a complete and buildable kernel; pm me and i will give proof, or the code if you can build and want to work on this. This is not x86/x64 work obviously so is not for those without ability: Need to do some heavy lifting to get recompile build happening for arm, qualcomm ' snapdragon nt :d. Otherwise is only emulation and not a good idea. This is 2be real. As non-x86/x64 support for nt (nt4 did ppc, mips, and now ia64) this kinda porting is not a foreign concept: There is sufficient info out there with reference to everything from softpc.new (inside ms code) to wow64cpu.dll and other x86/x64 specific init routines, spinlock and interrupt handling, asm code samps, bochs methods, qemu methods, et.al. Which can be used in one way or another or taken over if required: If all taken into account to paint big picture: Use of emulation technology methods for non-emulation project just opens up underlying logic. That is it. This is also why i suggest using wp7/ce7 base 4 init. Do not want emulation. Real deal here only. I refer to all these items above as observations which could be taken into account if need be: From tinykrnl, reactos, bochs, wine, efi, and other such things can make porting over kernel easier: At the end of the day, ce7/wp7 ' bldr, oal, nk.exe (or whatever derivatives thereof) will be 'firmware' in big picture. Another reason i am considering wp7 as base to strap is drivers are there to make a ce+bios or efi-type (?) pre-loader that takes all ce7 initialization further and passes on to nt (nk.exe runs including all setup as would be done by ntldr, a fake or psuedo-real ntdetect.com, system.hiv then passes data structs to our ntoskrnl.exe) and do all that needs be done. I can handle pc side completely but need bit of help with someone who gets nkglobal and other structures and use of platform builder with experience prefered in creation of new bsp. Maybe other ways - instead of ce, ie- grub, linux, openbios, openefi, but either way just want to prove it could be done is all.
Click to expand...
Click to collapse
anybody here capable?

to quote Da_G:
Yup, RustyGrom pretty much has it covered. First, it's called "CE" for Compact Edition, and this is not a misnomer in any way. The system is designed to be as compact as possible (There are build-time switches for everything, so you can toggle off nearly all the components to acheive a very "light" image) obviously, including drivers for components not present would be a waste of space, as they would never get used. So there are none included. On the PC side of things the BIOS provides a basic level of functionality using a standard interface so generic drivers are created to bring the platform up to that level, and from there vendor-specific drivers can be loaded.
If you want to put an embedded device in terms of a desktop computer and loading Windows 7 on it, you start out with a fully assembled computer (video card, motherboard, cpu, ram, etc.) - power it on. It loads up the BIOS which initializes the basic hardware and begins to load the rest from the hard drive. The embedded device loads up the NAND XLDR, which provides only flash read/write support. The XLDR then loads the "EBOOT" or "IPL" into ram on typical devices. HTC doesn't use the EBOOT/IPL model as such (here already we're breaking away from the "standard" even further) and instead has that split out into mARM AMSS (a custom designed RtOS that loads and runs the Modem ARM CPU) and SPL. Once the AMSS loads the SPL into ram and executes it, the SPL initializes the aARM (apps ARM CPU), does various checks (are we in update mode? do we need to expose a flash interface to update the rest of the OS? do we just boot up the os and move aside?)
Then finally you get past the highly device-specific code and on to the (slightly) more generic CE Kernel/drivers which get copied into ram by the SPL and executed (Native Kernel/XIP partition)
So, how different is CE7/WP7 from that model? (Which is the model we have now in CE5.x/WM6.x) - The mARM AMSS provides a different interface and initialization proceedure. That means any of the WP7 drivers from a donor device we might port from would not work at all with our current AMSS. Which in turn means no boot without re-writing the drivers/kernel or AMSS.
So to compare it to a desktop PC once again, we need to write a BIOS, a Hardware Abstraction Layer, and a set of drivers for each component on the system (likely a good deal of the drivers would be usable once the rest is done)
Do I sound jaded yet? Yes, yes I am It's probably a factor of 10 more complicated than I thought it would be initially.
Here's the JTAG pinouts that need to be connected, btw. There are pins on both sides of the motherboard which also is truely a pain in my ****, as i originally intended to mount an external port on the HD2 so I could easily keep a JTAG connection with it, but you basically have to remove the entire motherboard to maintain a reliable connection, which really precludes running it on a live device.
Click to expand...
Click to collapse
JTAG working now .

Ummm expect to hear from Microsoft lawyers in 5....4....3....

RustyGrom said:
Ummm expect to hear from Microsoft lawyers in 5....4....3....
Click to expand...
Click to collapse
Yeah i would be in breach of the non-disclosure-agreement i signed so removed.
But i am in inner city cbd wifi hotspot area and jump around unsecured cafe signals and other businesses and also use proxy servers and..... on top of that..... my own added tweaks for safe measure!
so, cafe+wifi+proxy, +other_anon, means there is absolutely no chance.

RustyGrom said:
Ummm expect to hear from Microsoft lawyers in 5....4....3....
Click to expand...
Click to collapse
reading your stuff on ce7. is this a bad idea you think? or not possible? no interest? i think it can be done.

ntonhd2 said:
reading your stuff on ce7. is this a bad idea you think? or not possible? no interest? i think it can be done.
Click to expand...
Click to collapse
I just don't think it's possible or worth it to bother trying to port NT to ARM while Microsoft is doing the same already. You're not going to be able to put together the team required meanwhile hiding from MS. It's just a stupid idea imo and really has no benefit. I mean what's your end goal here? To run Win7 on our devices?

Judging from this and other posts you have made, I suspect the most "source" you have is the "Windows Research Kernel", which is the source for a portion of ntoskrnl.exe from Server 2003 SP1, approximately. That would be no-where near enough, and it's not even enough to compile "just a kernel". It actually has a number of pre-compiled parts that it just pulls in.
Not to mention such a project is just asking to get shot down in a legal firefight. The WRK is given to academic institutions for studying the world's most popular desktop kernel, and is done so under a strict NDA.
ntoskrnl.exe by itself isn't enough to produce a workable OS anyway, especially one from the Server 2003 era.

hounsell said:
Judging from this and other posts you have made, I suspect the most "source" you have is the "Windows Research Kernel", which is the source for a portion of ntoskrnl.exe from Server 2003 SP1, approximately. That would be no-where near enough, and it's not even enough to compile "just a kernel". It actually has a number of pre-compiled parts that it just pulls in.
Not to mention such a project is just asking to get shot down in a legal firefight. The WRK is given to academic institutions for studying the world's most popular desktop kernel, and is done so under a strict NDA.
ntoskrnl.exe by itself isn't enough to produce a workable OS anyway, especially one from the Server 2003 era.
Click to expand...
Click to collapse
Sigh.. why don't people read before they make these ridiculous and thoughtless posts? Realize that there are people from Microsoft ON these threads. Also, RESEARCH IN DEPTH BEFORE POSTING SUCH A THREAD.

snickler said:
Sigh.. why don't people read before they make these ridiculous and thoughtless posts? Realize that there are people from Microsoft ON these threads. Also, RESEARCH IN DEPTH BEFORE POSTING SUCH A THREAD.
Click to expand...
Click to collapse
There are more microsoft people on xda than most realize .

RustyGrom said:
I just don't think it's possible or worth it to bother trying to port NT to ARM while Microsoft is doing the same already. You're not going to be able to put together the team required meanwhile hiding from MS. It's just a stupid idea imo and really has no benefit. I mean what's your end goal here? To run Win7 on our devices?
Click to expand...
Click to collapse
sure, sourcecode factor (nda) and secrecy/MS are complexities: but not as hard as people think here: it is TWO COMPLETELY DIFFERENT THINGS TO TRY AND GET WINDOWS7-ON-ARM to what I suggested (NT-CONCEPT-ON-ARM-WITH-Native-CLI) and no I would not use WRK sourcecode (lol) as part of my daywork i have access to (not ce) full sourcecode.
see my last post here,
can be done .

hounsell said:
Judging from this and other posts you have made, I suspect the most "source" you have is the "Windows Research Kernel", which is the source for a portion of ntoskrnl.exe from Server 2003 SP1, approximately. That would be no-where near enough, and it's not even enough to compile "just a kernel". It actually has a number of pre-compiled parts that it just pulls in.
Not to mention such a project is just asking to get shot down in a legal firefight. The WRK is given to academic institutions for studying the world's most popular desktop kernel, and is done so under a strict NDA.
ntoskrnl.exe by itself isn't enough to produce a workable OS anyway, especially one from the Server 2003 era.
Click to expand...
Click to collapse
What does this statement really mean?
might be a bad idea on hd2, fine, accepted, but your comment at the end doesn't make sense to me. so, ntoskrnl.exe for wp7 or nt4 (another era than 2003 .net) would make a difference? that is silly. besides, i made it clear that a psuedo-firmware setup would be required to setup the datastructures that NTLDR would prepare (along with NTDETECT.COM, and bios+pci_bus+ACPI interaction, (plus system or setupreg.hiv)), etc: so what are you saying exactly? my point was to not run any win32 or win64 gui or subsystem. never even mention win32k, gdi, etc. I was very clearly talking about native cli (ntdll.dll) and a prompt- maybe usb keyboard- as ARM NT Conceptual. Please, enlighten me . PS> yeah, I know the wrk and am fully aware of \prebuilt\ libraries and obj code: but, no, I was not intending on using this as base. I admit, hd2 nt prob bad idea: btw was ARM NT concept more than anything! and yeah, with the secrecy and legal issues it would be too complex and overwhelming to do so, accepted, but if I were truly to do this NO i would not use WRK lol .
And regarding Microsoft, yes, I accept that there are a LOT of employees on xda and it is crawled and watched for obvious reasons: covered that.
PPS> re WRK, no, would (if i were to try doing this that is) use what I already have access to as part of my work> under full NDA I have full source to a few different bases including all of 2003 and even HyperVServer and AzureOS trees. .
unfortunately I do not have windows phone 7 code access though! Thanks.

RustyGrom said:
I just don't think it's possible or worth it to bother trying to port NT to ARM while Microsoft is doing the same already. You're not going to be able to put together the team required meanwhile hiding from MS. It's just a stupid idea imo and really has no benefit. I mean what's your end goal here? To run Win7 on our devices?
Click to expand...
Click to collapse
Yep...... but there is a LOT of portability in the original nt4 and even w2k trees with alpha, mips, ppc, os2+posix, original softpc.new+ntvdm, and even newer, that would let this be done a lot easier than most realize: remember here that:
I AM NOT SAYING LETS RUN WIN32 ON OUR HD2: I AM SAYING LETS TRY RUN NTOSKRNL ON ARM.
big difference guys.
RustyGrom, I assume your talking about ARM-Cortex etc (msnt-2-arm)..... THIS is what i wanted to do but a much more lightweight and ms-testing-protocol-free-process; homebrew version in experimental state would ensure much speedier development: it is not that hard a concept to attempt to port over an earlier (nt4 or w2k) kernel FIRST then look at better (2003 & 7) memory management etc: the point here is PROOF OF CONCEPT NT ON ARM: that is it, like what you refer to. Read my first post: any remember tinykrnl.org? Alex Ionescu ? Reactos? it could be done a LOT easier than you all think!
only NT on ARM official stuff i am aware of is this (rumour/talk/concept/theory/design atm):
http://www.microsoft.com/Presspass/Features/2011/jan11/01-05SinofskySOC.mspx
http://thecoffeedesk.com/news/index.php/2009/04/23/net-could-be-key-in-windows-on-arm-netbooks/
http://www.osnews.com/story/24165/Windows_NT_on_ARM_It_s_a_Server_Thing
If you know NT like i do- then you would see it could readily be done but yes, I admit I do not know enoug about 'phones'/ce-platform. That's why I started THIS THREAD HERE: to get some thought on the subject is all .
what then would be major problems to overcome then and this is assuming concept of say:
0). hd2 power on
1). ipl/equiv
2). hspl.
3). magldr
4). dft leo70 rom
5). bsp/oal, bldr/uldr, OS.NB ->(NK.EXE).
6). remap, reinit, load and place (prep) data structures expected by ntoskrnl.exe (osloader, detect, pci, bios, etc).
7). jump to ntoskrnl.exe
?

For the record, a few years ago i did this exact thing: ported nt kernel over to another platform. myself and others re-wrote ntoskrnl.exe (+hal+drivers) and integrated osloader.exe(ntldr), and all data structures as would be passed to kernel from ntldr, registry system hiv, ntdetect, missing bios, missing interrupt+dma+pci-bus+acpi+power, etc into one (debug/xdk) single DEFAULT.XBE.
it only worked on XDK debug kit xbox consoles with serial+scsi+128mbRAM (and a custom lpc debug mod) but it worked. using code from intel and tianocore EFI/UEFI toolkits (and bits and pieces from here and there) and concepts such as PALcode as used by non-x86 osloader (.exe not ntldr) for simulacrum bios/firmware you can pass a predefined set of structures to ntoskrnl and ensure processor regs etc ARE ALL GOOD AND SYSTEM IS READY then call into KiSystemStartup, ExpInitializeExecutive, and begin modified phase0 of NTOSKRNL.EXE.
similar thing was done with CE.NET for Xbox - a default.xbe with linux code b4 NK.NB0
worked and works .

anyway, how u wanna solve the next problems?
1)missing CL compiler for ARM with same set of features like CL for X86.
(CL version for ARM for WCE doesn't have all features supported and usually outdated)
2)this ARM compiler store exception info in other format (not SEH frames, but universal table for functions ".pdata")
3)which files u exactly wanna build for ARM? is it "ntoskrnl.exe bootvid.dll hal.dll"?
4)which final results u gotta got?
5)why u need touch WP7? u can just look to example code in Android kernel and implement something. so replace PC standard timer realization inside HAL.dll with QSD8250 specific timer code. it's much better to start.
how many ppl u have in ur team?

Cotulla said:
anyway, how u wanna solve the next problems?
1)missing CL compiler for ARM with same set of features like CL for X86.
(CL version for ARM for WCE doesn't have all features supported and usually outdated)
2)this ARM compiler store exception info in other format (not SEH frames, but universal table for functions ".pdata")
3)which files u exactly wanna build for ARM? is it "ntoskrnl.exe bootvid.dll hal.dll"?
4)which final results u gotta got?
5)why u need touch WP7? u can just look to example code in Android kernel and implement something. so replace PC standard timer realization inside HAL.dll with QSD8250 specific timer code. it's much better to start.
how many ppl u have in ur team?
Click to expand...
Click to collapse
************************************************************
update: Attached is ARM low level bootloader just built; this could be used to load LDR and then ntoskrnl.exe .
************************************************************
Please let me know your thoughts and please try to get this to run with debug if you can and pass results & thoughts back to me - Cheers. Hopefully it built ok. What do you think of using this method then? but with FULL & PROPER NTOSKRNL.EXE!
************************************************************
Hi Cotulla, thanks for your reply: appreciate it here.
[also much thanks for hspl, magldr, dft android, leo70ROM. .]
ok, sorry if this is a bit all over the place, i have cut and pasted my answers around to try clean it up but it is late and i think my brain is a bit dead sorry, but answers are here anyway . hope makes sense. firstly please have a look at this video and let me know what you think .
http://www.youtube.com/watch?v=RFNuY2OFRjU
that is ARM..... i am going through build environment and sourcecode now..... thoughts?
http://www.youtube.com/watch?v=n3v4YC9RT-g&feature=related
can learn a lot from wine. i agree with you on linux. same for virtualization, emulation, etc, like bochs qemu everything . sandboxing and hypervisor unveils a LOT . another thing i wanted to ask you was what do you think of FPGA technology for reverse engineering unknown systems? for example, if i were to start almost any project, like say leo70DFTrelease, or NT on Xbox, or whatever, doesnt matter, i think it is worth spending the time or money (for private company to do it for you) and have an FPGA version of the target device being hacked (hd2 in leo70rom case) and then undo the software problems from a hardware logic perspective. just the way i have worked on things many times and it works for me anyway. but I digress.......... . if i were to have done wp7hd2 (leo70rom) and magldr, then i would have had to have had (for me, not as good a dev as you) a FPGA based HD2 made up that ran in every way same but with which i could get right in there and do whatever i needed to do to see response& debug. let me know what you reckon... ok... digress now :
1)missing CL compiler for ARM with same set of features like CL for X86.
(CL version for ARM for WCE doesn't have all features supported and usually outdated)
what features specifically we need here?
what about tweaking this:
http://reactos.colinfinck.de/files/RosBE-Windows/RosBE-ARM-1.0.exe
2)this ARM compiler store exception info in other format (not SEH frames, but universal table for functions ".pdata")
http://www.reactos.org/wiki/PSEH
http://www.reactos.org/forum/viewtopic.php?f=9&t=5716
reading up on _IMAGE_CE_RUNTIME_FUNCTION_ENTRY. just going over stacks and frames and overall exception handling on ARM. are there any issues with reverse execute, virtual unwind? for this type of execution- how would you handle?
more to the point- how would you do this project lol.
problems with prolog/epi? what about moving over x86 asm code? i am right now typing this to you whilst getting updated on specifics on registerslooking at emulators to see this in action. i am reading these here. let me know if on right path and please put up links to whatev will make this project concept a reality . Cheers .
see here
http://www.cl.cam.ac.uk/~mwd24/phd/swarm.html
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
http://www.codeproject.com/KB/threads/StackWalker.aspx?msg=2818356
can you recommend any compiler, emulator, os, setup, even equipment (JTAG etc etc) i should use, buy, try?
3)which files u exactly wanna build for ARM? is it "ntoskrnl.exe bootvid.dll hal.dll"?
depends on method: i agree (see below) that probably android or (htc-)linux is probably more likely to work but leo70_rom made me think maybe jump from (touch wp7) nk.exe? and are you saying use linux as in LinuxBios type setup?
would need emulated bios, pci bus fixed up (?), QSD timer HAL, ACPI (?), etc ,,, so probably would end up with the following:
a) BIOS (ce7 exe or linux ?): options here could be to make NT think it is running on PALcode, uEFI, or standard ACPI BIOS (your thoughts?). I think uEFI (tianocore/Intel) is best bet here perhaps. this would include MBR code (efi equiv or pal equiv depending) and any psuedo-real or "real" initialization i think.
b) mbr execution merged to and included in above, bootsect. in sim' 'firmware'.
c) $LDR$ @ OSLOADER.EXE (osloader.exe is non-x86 ntldr as im sure you know WITHOUT the code to run ntdetect.com and acts in PALcode architecture to pass on predefined data structues from firmware: tells NTOSKRNL.EXE where and what 2 execute).
d) HAL.DLL (timer, power/acpi, spinlocks, interrupts). another reason i leant towards WP7 as pre-NT launcher is because i assumed that something like BSP, OAL, etc, could be maybe used as base: if not for code, then logical base. what base(s) did you use to create WP7 if i may ask? ie: CE7? I have just installed Platform-Builder. but yeah, i here you regarding android/linux kernel example: ultimately are you saying better, easier, more logical, to go with android/linux you think Cotulla?
e) BOOTVID.DLL
f) KDCOM.DLL (if wp7 would make use of KITL?)
g) drivers as required including the following: ntbootdd.sys (?) might allow easier diversion from bios lack of INT13 and other support: remap to whatever can handle this properly. equivalents for ACPI.sys, filesystem drivers, other power, basics. how should i be looking at things from NT side of things, as in \ObjectTypes like \??, \Global?? etc .... and items like ROOT device in ARM (either CE or linux preloaded) context? any thoughts on how object manager would need to be brought up? for me, now, that is where it gets crucial and is core.
h)SMSS.EXE (NATIVE.EXE) but to begin with could just get drivers and all that working first and strap up into cmdcons (SPCMDCON.SYS). just blue-screen SMSS (windows setup) enough to prove kernel to run on ARM cpu. your thoughts?
i) SYSTEM reg key hive (setupreg.hiv etc?)
...
4)which final results u gotta got?
Tinykrnl type native CLI.
http://www.betaarchive.co.uk/imageupload/1193217573.or.99024.jpg
with USB keyboard support like htc-linux then go from there..... would love a prompt from which could just call any given call - be it CreateProcess or NtCreateProcess or ANYTHING: and it just does it (with debug/KITL) without question . but native NT command line is good for now. not going near win32.
5)why u need touch WP7? u can just look to example code in Android kernel and implement something. so replace PC standard timer realization inside HAL.dll with QSD8250 specific timer code. it's much better to start.
yeah....
I thought linux probably would end up being better: just liked symmetry of windowsCEx-strapping-windowsNTx: making a windowsCE-EFI/BIOS: but yeah, something like LinuxBios (android kernel etc) would be a lot easier in the end yeah? All this is overly simplified and very conceptual but there are basic answers. . once a solid idea has been formed then this could actually be done i think. and before Microsoft . Do you believe Reactos-ARM-build environment could be used? Am i missing anything? 9 people team+myself (+any help you can offer) would make 10 (+1). I think this is a good idea to at least try and i believe with your assistance, guidance, well, it would get done and then complete the HD2 line up fully. . In conclusion, right now, I need ARM emulator software, platform builder, and fully working Compact Edition 7 on HD2 to get some more thoughts and try few things out in platform builder debug then can get final decision, design, plan and start to get everything working. Even though will probably go with Linux/Android obviously as above, I still need 2see init on CE7 on HD2 and be able 2use this along with whatever else we can! have a look at all above links... thanks.
Cotulla, thanks again 4reply>please PM [email protected] something but not posting..... await your PM.
what about this ( http://research.microsoft.com/en-us/projects/singularity/ ) could be of use to NT port with respect to CLR ? haha, or just outright hd2 port Microsoft RDK OS ' singularity ' ? .
************************************************************
update: Attached is ARM low level bootloader just built; this could be used to load LDR and then ntoskrnl.exe .
************************************************************
Please let me know your thoughts and please try to get this to run with debug if you can and pass results & thoughts back to me - Cheers. Hopefully it built ok. What do you think of using this method then? but with FULL & PROPER NTOSKRNL.EXE!
************************************************************

I don't have big knowledge of Windows NT system, but I think it's must be enough to provide basic stuffs for kernel start up.
I guess NT using only int13 services for reading data from disk, int15 services used to detect memory configuration and int10 for initial boot mode.
Because it's embedded hardware, the devices in the system are fixed and limited. So it's enough to provide fixed values for kernel, like available ram memory range.
No need of using any complex systems with CE / Linux.
About CE, you can get almost full kernel sources in PB6.0, trial can be downloaded from MS site.
afaik it's enough to load kernel and dependent modules (drivers) to ram and then run them. after this action kernel drivers should able to run properly on hardware.
About Reactos, I appreciate work of involved people, but I doubt that it's stable
About this project, I don't know yet if I will contribute. I am looking how much it's interesting for me
I always have interesting different things in my hobby as well, so I have choose that to do As well, me is part of DFT team, I need discuss it with them
Now I am asking you to understand more details about your idea(s)

Cotulla said:
I don't have big knowledge of Windows NT system, but I think it's must be enough to provide basic stuffs for kernel start up.
I guess NT using only int13 services for reading data from disk, int15 services used to detect memory configuration and int10 for initial boot mode.
Because it's embedded hardware, the devices in the system are fixed and limited. So it's enough to provide fixed values for kernel, like available ram memory range.
No need of using any complex systems with CE / Linux.
About CE, you can get almost full kernel sources in PB6.0, trial can be downloaded from MS site.
afaik it's enough to load kernel and dependent modules (drivers) to ram and then run them. after this action kernel drivers should able to run properly on hardware.
About Reactos, I appreciate work of involved people, but I doubt that it's stable
About this project, I don't know yet if I will contribute. I am looking how much it's interesting for me
I always have interesting different things in my hobby as well, so I have choose that to do As well, me is part of DFT team, I need discuss it with them
Now I am asking you to understand more details about your idea(s)
Click to expand...
Click to collapse
sure....... . anything ReactOS -freeldr, any arm code, whatever, is just to get basic idea up- to see the actual jump whilst watching (be it by jtag, kitl, usb, or telepathy interface to QD) and go from there; although im sure you could use ReactOS arm code lowlevel bootloader to jump into EITHER "freeldr" or proper "ntldr" or "osloader.exe" (modified of course to have no pci bus scan and the rest.....) that is the dilemma: either jump COMPLETELY like winmo6-android with all structures setup DIRECTLY INTO KERNEL and avoid the whole LDR side of things in that sense anyway; or, well, totally from scratch rebuild loader and subsequently deal with 'firmware' issues... i really do not care in the end if its a jump from one kernel to another (one os to another) because project here is to RUN NT ON ARM/HD2 and not to necessarily have it homogenous down to LDR.
as long as thread, memory, native api, other calls, all that, is truly ntoskrnl = you are running nt on your arm hd2! .
LDR does not matter.... total new rebuild or jump.... whatever comes first .
Thanks Cotulla, yes, we understand where your coming from re do not need linux, ce, and complexities there and i agree: just want to use these for initial testing and deployment of early code with some kitl, debug.... on other notes, trying to put all into organized groups, slowly but surely yes, with bit of faith we will get there in the end .
if totally up to me i would probably take intel/tianocore EFI specification as the base if this could somehow be easily made to run on ARM in this particular context. ie EFI on a HD2!
look at this raw control power!>>> http://www.ami.com/support/doc/AMI_Debug_UEFI_Dsheet_PUB_2008-06-10.pdf
also along these lines, just briefly (is helpful in concept design):
http://x86asm.net/articles/uefi-hypervisors-winning-the-race-to-bare-metal/index.html
http://sourceforge.net/projects/gnu...orig.tar.gz/gnu-efi_3.0h.orig.tar.gz/download
http://x86asm.net/articles/introduction-to-uefi/
http://sourceforge.net/projects/efidevkit/
http://www.logic.nl/Products/Technology/BIOS-and-EFI.aspx
ok, summing up thoughts here>>>
0) object manager and objects; going over arm & ce7, as well as winmo6 and other ce, and comparing with nt and win32/64; just looking at how on final arm release, the \ObjectTypes will be different in the end. very interesting stuff.
1) LACK-OF. no pci bus which is highly expected by ldr/detect so make kernel prob see system in 'PALcode' or EFI mode. pass ldr data structs to kernel in that type of form. otherwise gets very messy and we are not going to hack around because you will end up with an emulator !. this will work but key is determing what 'firmware' passes this data to nt kernel - not from our perspective- but as NT.
2) BIOS. INT services are not used by kernel in that way after it becomes supervisor so will redo drivers unless preload remap somehow. INT only there during ntldr (or can load in ntbootdd.sys to supply these) and this is all pre-phase0 and is very early on.
3) HAL and clk
4) INT services are not used by kernel in that way after it becomes supervisor so will redo drivers unless preload remap somehow. INT only there during ntldr (or can load in ntbootdd.sys to supply these) and this is all pre-phase0 and is very early on.
5) kitl and kdcom
6) registry to pass on (setupreg).
8) filesystem, screen, other drivers
9) final native cli (ntdll.dll) or maybe initially just spcmdcon.sys.
above not in order ..... sorting it all out though .....
ok, looks daunting but like i said before you could get up an nt kernel in setup mode with setup ldr and drivers and old blue screen "dos" mode native subsystem which uses the SMSS.EXE and NTDLL.DLL that are seperately contained in \i386\system32\ or \cmdcons\system32\ - very limited subsystem but is full nt os at kernel . so........ if not ce and not linux preloading, WOW . it is quite an amazing project but doable; so basically just need to see how this armldr (low level strap - be it Reactos or my own clean job- will do both) code runs on the device itself and step by step add the rest in as required! but i still believe actual dev be better jumping from preexisting environment having kitl or some sort of serial or usb debug already there and then working way down to lowest possible level; so, basically, working backwards down to processor.
Doing it all from scratch and CLEAN . (in the end!). .

my brain just straight up exploded.
thanks a lot.

http://www.youtube.com/watch?v=xKc_XGuvNIk .

for the record:
so far without any errors have successfully been able to build the ntdll.dll, hal.dll, smss.exe, bootvid.dll, fastfat.sys, for ARM with no modifications at all, but not yet done a build on the LDR or NTOSKRNL.
just testing compiler here is all and not writing new: this is very early on and i have changed absolutely nothing.
once fill in gaps will give it a go on hd2.
attached.

[Guide] Easy Native Windows Development (N00b Friendly!)

Hello guys,
Today I'm going to provide an easy and step-by-step guide (With support) to develop your very own first native Windows app!
I'll also provide screenshots and code snippets, so it's easier to understand.
This guide and app will be written in the simplest language I know and I use, Microsoft Visual Basic. Now, before anyone starts hating; Visual Basic is a programming language which works with and on top of the .Net framework. As the name states, you can visually design your application and code it with very basic code.
Visual Basic is also very powerful, as it can be used to communicate with the Windows OS and with the computer's hardware (And especially COM ports)
This guide will focus on the use of the WinForms (Win32) API, so we won't be using any old command prompt (As I think tutorials using the command prompt are quite hard to understand and pretty stale)
#1. Prerequisites:​
Before we can begin creating our first app, you'll need some software:
Microsoft Visual Studio Express 2012 (For Windows Desktop)
Windows 7 or 8 (For Windows Vista-, you can use Visual Studio 2010 or earlier!)
A cup of your favorite hot beverage
Some patience
and courage
Once you have acquired all of those, you can start download- and installing the software (All other prerequisites are provided in the package), this is where your hot beverage will come in handy (Alternatively, you can go for a nice cigarette or for a quick pop-down-the-shop).
I decided to create a series of videos on YouTube, for this thread.​
So, here we go, I guess
Episode 1; Performance Counters and Progress Bars:
If the YouTube video is not visible/available, try watching it here: http://youtu.be/geePfZzjYCA
Episode 2; XDA-String-Loader:
If the video is unavailable, watch it here: http://t.co/LO1q1jTIfE

Downloads
Note: All downloads in this post are just VB source code. They are licensed under either GPL2.0 or GPL3.0 - So feel free to download, experiment and post what you've done!
GitHub Source Code Repositories: https://github.com/Beatsleigher/XDA_Visual_Basic_Tutorials/

Good Qs and As
This post is reserved for good questions and answers.​

User Contributions
This post is reserved for user contributions.​
Post your code and show the others what you have achieved!

Reserved..
--- Reserved ---

Reserved..
--- One more reserved post ---

develop your very own first native Windows app
Click to expand...
Click to collapse
Visual Basic is a programming language which works with and on top of the .Net framework
Click to expand...
Click to collapse
And there you go, feel free to experiment with this code and play around with it. It is licensed under the GPL v2, as of now. I will create more posts in this thread over time and add more projects for you to work on.
Click to expand...
Click to collapse
I'm crying blood, sorry D:

Yeah, you do kinda contradict yourself by calling it a native application and then using Visual Basic .NET (I must say, I have little faith in the tutorial being accurate if you cant even name the language properly). All .NET languages are run in a VM which by definition is not native I would hardly call it powerful either, it offers nothing that any other .NET language can't do faster and manages to **** things up in the process. Your statement about COM. Wtf??? VB.net makes COM access no easier or harder than anything else. The fact it is easy to access COM (which is something rarely used these days, although I do use it) is purely down to system.io.ports which is a generic .NET library and not a VB.net feature.
There is a good reason for command prompt based programs being the first step. They are simple. You dont have to worry about events and OOP programming early on. You can just sit down, learn wtf an integer is, bit of flow control and what iteration is etc.

SixSixSevenSeven said:
There is a good reason for command prompt based programs being the first step. They are simple. You dont have to worry about events and OOP programming early on. You can just sit down, learn wtf an integer is, bit of flow control and what iteration is etc.
Click to expand...
Click to collapse
And of course to use much simpler language, like Pascal. Console.ReadLine can confuse beginners.

Guys, maybe I... phrased things wrong.
It uses the .Net framework, but the language itself is native code.
The only things that run on top of the .Net FW are the new tools. Everything else is native code.
Whoops.

Beatsleigher said:
Guys, maybe I... phrased things wrong.
It uses the .Net framework, but the language itself is native code.
The only things that run on top of the .Net FW are the new tools. Everything else is native code.
Whoops.
Click to expand...
Click to collapse
you have just perfectly demonstrated that you don't have a clue what the .net framework is or how VB.net relates to it.
quick description of what really goes on when you hit F5 in visual studio (and for simplicities sake I am assuming we are in release mode not debug mode).
You hit f5.
The Visual Basic .net compiler analyses the source code, links it all up etc.
It then output MSIL. MicroSoft Intermediate Language.
The .NET framework is then a JIT dynamic recompiler (read, interpreter) which interprets the MSIL and executes the output.
It is not native code. The .NET framework is not just a set of tools.
only confusion which may arise is that .NET is now a part of the windows runtime, but it is not native any more than java is (same principal operation).

JIT compilation != dynamic recompilation != interpretation. Please don't confuse them.
JIT compilation ("Just-In-Time", what .NET and Java do, as well as recent JavaScript engines) takes data that is *not* machine code (it can be a binary intermediate language, such as Java bytecode or .NET Common Intermediate Language ("MSIL" is obsolete; it's a public standard now), or it can be normal source code, such as JavaScript) and turns it into machine code immediately before the program runs. This introduces a delay at program startup, but thereafter the program runs almost as fast as it would if written in C and compiled directly to native code.
Dynamic recompilation takes machine code for one processor, generally already loaded into memory for execution, and translates it to machine code for a different processor before it is executed. The translated machine code is then stored back into memory so that the next time that code would be executed (for example, if it's in a loop or a function that is called multiple times) it doesn't need to be translated again. Dynamic recompilation operates on machine code, which (unlike intermediate language) is processor-specific and is not intended to be further compiled; this makes it significantly slower in most cases. It's largely replaced outright emulation (in which an entire CPU's state is modeled on some other CPU, and each instruction is run through the emulated CPU unmodified) as a way to execute a program written for one instruction set architecture on another ISA because it's faster than emulation, but it's still very slow.
Interpretation is like emulation, except it operates entirely on instructions which aren't machine code at all; you can write an interpreter for intermediate language (and that's basically how early versions of Java worked), but it's typically used for script languages (until recently, interpretation is how JavaScript was executed). An interpreter is a program that takes the interpreted language and figures out what it means in terms the CPU understands, then does that. For example, a CPU doesn't understand that "+" means addition; to a CPU, + is nothing except a number, just like any other ASCII character. It's up to an interpreter to recognize that + is supposed to be an operator, and that the 1 and 2 in 1+2 are supposed to be operands, and that they need to be converted from ASCII characters to the actual values 1 and 2 (which aren't even printable values in ASCII) and then to do the operation and store it somewhere. As you might expect, interpretation is *extremely* slow.

thanks for the videos. don't let the trolls get you down!

squeezyb said:
thanks for the videos. don't let the trolls get you down!
Click to expand...
Click to collapse
No worries, man
I tend to ignore such posts, as I don't see reason to argue
CyanogenModded Very China-like, from my Samsung Galaxy S III
LG Familyguy59/Beatsleigher

[DEV][LIB][1.1] SysLib. Class Library for .Net Applications!

Hey guys!
A few months back, I posted an app called DetectCPU. It got quite some attention, which I did not think it would. I hoped so, but I thought that it'd get ignored like other projects of mine. But that did not happen.
In the thread, I was asked if I couldn't port it to C# or C++ or something so one could make something like CPU-Z.
Well, today I didn't do that, no. Today I created a .Net lib (.dll) containing most of the information that DetectCPU gets and more!
It's called SysLib, it's coded in Visual Basic.Net and can be used with ANY .Net application (.Net languages include: Visual basic.Net, C#, Visual C++)
At the moment it contains but three classes: CPU, Baseboard and Battery within a namespace called GetInfo.
Here are the prerequisites for your application:
.Net 2.0 or higher
Must use .Net framework!
Windows Vista and higher is recommended as some WMI queries are not available for Windows XP and lower.
How to use the lib:
Add SysLib.dll as a reference to your program.
Import SysLib.GetInfo to your class/es (To get the information)
Add the class as a variable (Private cpu As SysLib.GetInfo.CPU = New CPU)
Have fun!
Click to expand...
Click to collapse
GitHub Homepage for SysLib: http://beatsleigher.github.io/SysLib/
Download: Sourceforge
Source Code: GitHub
License:
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc.
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
This version of the GNU Lesser General Public License incorporates
the terms and conditions of version 3 of the GNU General Public
License, supplemented by the additional permissions listed below.
0. Additional Definitions.
As used herein, "this License" refers to version 3 of the GNU Lesser
General Public License, and the "GNU GPL" refers to version 3 of the GNU
General Public License.
"The Library" refers to a covered work governed by this License,
other than an Application or a Combined Work as defined below.
An "Application" is any work that makes use of an interface provided
by the Library, but which is not otherwise based on the Library.
Defining a subclass of a class defined by the Library is deemed a mode
of using an interface provided by the Library.
A "Combined Work" is a work produced by combining or linking an
Application with the Library. The particular version of the Library
with which the Combined Work was made is also called the "Linked
Version".
The "Minimal Corresponding Source" for a Combined Work means the
Corresponding Source for the Combined Work, excluding any source code
for portions of the Combined Work that, considered in isolation, are
based on the Application, and not on the Linked Version.
The "Corresponding Application Code" for a Combined Work means the
object code and/or source code for the Application, including any data
and utility programs needed for reproducing the Combined Work from the
Application, but excluding the System Libraries of the Combined Work.
1. Exception to Section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License
without being bound by section 3 of the GNU GPL.
2. Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a
facility refers to a function or data to be supplied by an Application
that uses the facility (other than as an argument passed when the
facility is invoked), then you may convey a copy of the modified
version:
a) under this License, provided that you make a good faith effort to
ensure that, in the event an Application does not supply the
function or data, the facility still operates, and performs
whatever part of its purpose remains meaningful, or
b) under the GNU GPL, with none of the additional permissions of
this License applicable to that copy.
3. Object Code Incorporating Material from Library Header Files.
The object code form of an Application may incorporate material from
a header file that is part of the Library. You may convey such object
code under terms of your choice, provided that, if the incorporated
material is not limited to numerical parameters, data structure
layouts and accessors, or small macros, inline functions and templates
(ten or fewer lines in length), you do both of the following:
a) Give prominent notice with each copy of the object code that the
Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license
document.
4. Combined Works.
You may convey a Combined Work under terms of your choice that,
taken together, effectively do not restrict modification of the
portions of the Library contained in the Combined Work and reverse
engineering for debugging such modifications, if you also do each of
the following:
a) Give prominent notice with each copy of the Combined Work that
the Library is used in it and that the Library and its use are
covered by this License.
b) Accompany the Combined Work with a copy of the GNU GPL and this license
document.
c) For a Combined Work that displays copyright notices during
execution, include the copyright notice for the Library among
these notices, as well as a reference directing the user to the
copies of the GNU GPL and this license document.
d) Do one of the following:
0) Convey the Minimal Corresponding Source under the terms of this
License, and the Corresponding Application Code in a form
suitable for, and under terms that permit, the user to
recombine or relink the Application with a modified version of
the Linked Version to produce a modified Combined Work, in the
manner specified by section 6 of the GNU GPL for conveying
Corresponding Source.
1) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time
a copy of the Library already present on the user's computer
system, and (b) will operate properly with a modified version
of the Library that is interface-compatible with the Linked
Version.
e) Provide Installation Information, but only if you would otherwise
be required to provide such information under section 6 of the
GNU GPL, and only to the extent that such information is
necessary to install and execute a modified version of the
Combined Work produced by recombining or relinking the
Application with a modified version of the Linked Version. (If
you use option 4d0, the Installation Information must accompany
the Minimal Corresponding Source and Corresponding Application
Code. If you use option 4d1, you must provide the Installation
Information in the manner specified by section 6 of the GNU GPL
for conveying Corresponding Source.)
5. Combined Libraries.
You may place library facilities that are a work based on the
Library side by side in a single library together with other library
facilities that are not Applications and are not covered by this
License, and convey such a combined library under terms of your
choice, if you do both of the following:
a) Accompany the combined library with a copy of the same work based
on the Library, uncombined with any other library facilities,
conveyed under the terms of this License.
b) Give prominent notice with the combined library that part of it
is a work based on the Library, and explaining where to find the
accompanying uncombined form of the same work.
6. Revised Versions of the GNU Lesser General Public License.
The Free Software Foundation may publish revised and/or new versions
of the GNU Lesser General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Library as you received it specifies that a certain numbered version
of the GNU Lesser General Public License "or any later version"
applies to it, you have the option of following the terms and
conditions either of that published version or of any later version
published by the Free Software Foundation. If the Library as you
received it does not specify a version number of the GNU Lesser
General Public License, you may choose any version of the GNU Lesser
General Public License ever published by the Free Software Foundation.
If the Library as you received it specifies that a proxy can decide
whether future versions of the GNU Lesser General Public License shall
apply, that proxy's public statement of acceptance of any version is
permanent authorization for you to choose that version for the
Library.
Click to expand...
Click to collapse
Want to read an awesome review about SysLib? Check out the review by Will Verduzco here!

Changelog
Changelog/s​
V.1.0 said:
Started Project
Added Namespace GetInfo
Added Class CPU
Added Class BaseBoard
Added Class Battery
Click to expand...
Click to collapse
V1.1 said:
Added Class BIOS
Added Class BootConfig
Added Class CDROMDrive
Added Class ComputerSystem
Click to expand...
Click to collapse

-deleted-

It's an offtopic, but I'm curious to ask you.
Why do you need Nvidia GeForce 770 GTX? I have 2 times slower graphics, but it doesn't affect on my productivity. I advise you to buy SSD

Useless guy said:
It's an offtopic, but I'm curious to ask you.
Why do you need Nvidia GeForce 770 GTX? I have 2 times slower graphics, but it doesn't affect on my productivity. I advise you to buy SSD
Click to expand...
Click to collapse
Gaming perhaps... Or high end 3d rendering, hell some render tasks will overtax a GTX770 even

Useless guy said:
It's an offtopic, but I'm curious to ask you.
Why do you need Nvidia GeForce 770 GTX? I have 2 times slower graphics, but it doesn't affect on my productivity. I advise you to buy SSD
Click to expand...
Click to collapse
I plan on learning C++ and Java and I'd like to add some awesome graphics and animations to my programs to make thrm more appealing. And to do that I need a rather high-end system. And the occasional game will also be installed.
Sent from my GT-I9505 using xda app-developers app