I added the project to GitHub. Heres the URL: https://github.com/jessenic/HaRET-WP7

Feel free to fork and submit pull requests! Also well known devs are more than welcome to the repo admin team.

Edit: Builds will become visible here whenever someone commits and the build did not fail: http://minecraft.digiex.org/jenkins/HaRET-WP7/

Also here is the Silverlight Launcher: https://github.com/jessenic/HaRET-WP7-Launcher/
Builds for the launcher: http://minecraft.digiex.org/jenkins/HaRET-WP7-Launcher/

===== HaRET pre-0.5.3-20120415_150816 =====
...

...
Running WSAStartup
Starting gui
In initdialog
Terminating haret due to unhandled exception (pc=00000000)

Originally Posted by spavlin

===== HaRET pre-0.5.3-20120415_150816 =====
...

...
Running WSAStartup
Starting gui
In initdialog
Terminating haret due to unhandled exception (pc=00000000)

What phone? What build or is it self built? If self built, what version of the CE compiler?

ace_dli.dll ace_ddi.zip

gx.dll gx.zip

Are you using the source on github, or the original source by the OP?

Replaced Rom, now GUI works

Stupid Question but important - Which MTYPE has HTC Trophy please?

And log is in attachment.

Thanks for functional Haret7 Launcher jessenic!

Edit: Haret7 launcher: "Install latest" without internet connection closes app.

http://msdn.microsoft.com/en-us/library/aa908734.aspx

UnlockPages
This function unlocks a specified range of pages in the virtual address space of a process, enabling the system to swap the pages out, if necessary. This function can be called only in kernel mode.

Syntax

BOOL UnlockPages(
LPVOID lpvAddress,
DWORD cbSize
);
Parameters
lpvAddress
[in] Address of the start of a region of committed pages that are to be unlocked.

cbSize
[in] Number of bytes to unlock.

Return Value
TRUE indicates success FALSE indicates failure. To get extended error information, call GetLastError.

Remarks
LockPages is referenced counted, so if the same thread does a LockPages twice, the second UnlockPages unlocks the pages.

Requirements
Header pkfuncs.h
Library coredll.lib
Windows Embedded CE Windows Embedded CE 6.0 and later

CeVirtualSharedAlloc

This function allocates read/write memory to the caller and read-only memory to other processes. This function is callable only in kernel mode.

Syntax

LPVOID CeVirtualSharedAlloc(
LPVOID lpvAddr,
DWORD cbSize,
DWORD fdwAction
);
Parameters
lpvAddr
[in] Starting address of the shared memory to be committed, or NULL if reserving shared memory.

cbSize
[in] Size, in bytes, of the memory reservation or allocation.

fdwAction
[in] Value that specifies the action.

This value must be a combination of MEM_RESERVE and MEM_COMMIT.

Value Description
MEM_COMMIT
Commits the memory specified by lpvAddr and cbSize, where lpvAddr must be an address previously reserved by CeVirtualSharedAlloc.
This value can also be NULL, which reserves and commits a region of size cbSize. This behaves like MEM_RESERVE|MEM_COMMIT.
MEM_RESERVE
Reserves a region in the shared read-only area. lpvAddr must be NULL.
Return Value
A pointer to the memory region that was reserved or committed indicates success. NULL indicates failure. To get extended error information, call GetLastError. If the caller is not fully trusted, the call fails with the error code ERROR_ACCESS_DENIED.

Remarks
You can free the memory region that was reserved or committed by CeVirtualSharedAlloc, using the VirtualFree function.

Freeing the memory allocated by CeVirtualSharedAlloc is similar to freeing memory allocated by the VirtualAlloc function.

Requirements
Header pkfuncs.h
Library coredll.lib
Windows Embedded CE Windows CE 5.0 and later

VirtualAllocCopyEx

This function reserves or commits a region of pages in the virtual address space of the specified destination process, hDstProc, and then dynamically creates an alias to the virtual memory given by the source process, hSrcProc, and the source address pAddr. Terminate the mapping by calling VirtualFreeEx. This function is callable only in kernel mode.

Syntax

LPVOID VirtualAllocCopyEx (
HANDLE hSrcProc,
HANDLE hDstProc,
LPVOID pAddr,
DWORD cbSize,
DWORD dwProtect
);
Parameters
hSrcProc
[in] Handle to the source process.

hDstProc
[in] Handle to the destination process.

pAddr
[in] Long pointer to the specified starting address in the source process, hSrcProc. This cannot be NULL.

cbSize
[in] Size in bytes of virtual allocation pointed to by pAddr in the hSrcProc process. This cannot be NULL.

dwProtect
[in] Type of access protection. If the pages are being committed, any one of a number of flags can be specified, along with the PAGE_GUARD and PAGE_NOCACHE, protection modifier flags.

For information about the possible flags for this parameter, see VirtualCopyEx.

Return Value
The base address of the allocated region of pages indicates success. NULL indicates failure. To get extended error information, call GetLastError.

Remarks
If you want to VirtualAllocCopy a physical or virtual buffer, if that buffer is not page-aligned then you will end up copying more data than you specified. If the start of the buffer is not page-aligned then you will also copy data before the start of the specified buffer, starting from the beginning of the page. If the end of the buffer is not page-aligned then you will also copy data after the end of the specified buffer, ending at the following page boundary.

This is a security issue if the copied buffer is ever passed to user mode. The user mode application will be able to access the surrounding data that is not part of the specified buffer. To protect the surrounding data, use a buffer that is page-aligned and an even multiple of pages in size. If that is not possible then passing the data to user mode puts it at risk.

For more information, see VirtualAllocEx and VirtualCopyEx.

Requirements
Header pkfuncs.h
Library coredll.lib
Windows Embedded CE Windows Embedded CE 6.0 and later

VirtualCopyEx

This function dynamically maps a virtual address to a physical address by creating a new page-table entry. Terminate the mapping by calling VirtualFree. This function is callable in kernel mode and in user mode, when the source and destination process handles are the active process.

Syntax

BOOL VirtualCopyEx(
HANDLE hDstProc,
LPVOID lpvDest,
HANDLE hSrcProc,
LPVOID lpvSrc,
DWORD cbSize,
DWORD fdwProtect
);
Parameters
hDstProc
[in] Handle to the destination process.

lpvDest
[in] Pointer to the destination memory, which must be reserved.

hSrcProc
[in] Handle to the source process.

lpvSrc
[in] Pointer to committed memory.

cbSize
[in] Size, in bytes, of the region. The allocated pages include all pages containing one or more bytes in the range from lpAddress to (lpAddress + cbSize). This means that a 2-byte range straddling a page boundary causes both pages to be included in the allocated region.

fdwProtect
[in] Type of access protection. If the pages are being committed, any one of a number of flags can be specified, along with the PAGE_GUARD and PAGE_NOCACHE, protection modifier flags. The following table shows the flags that can be specified.

For information about the available values for this parameter, see VirtualCopy.

Return Value
TRUE indicates success. FALSE indicates failure. To obtain extended error information, call GetLastError.

Remarks
This function is similar to VirtualCopy, except VirtualCopyEx requires handles to the source and destination process. For more information about this function, see VirtualCopy.

Requirements
Header pkfuncs.h
Library coredll.lib
Windows Embedded CE Windows Embedded CE 6.0 and later

VirtualSetAttributes

This function enables driver developers to change the per-page attributes for a range of virtual memory, which is usually copied from a physical location not known to the kernel. This function can be called only in kernel mode.

Syntax

BOOL VirtualSetAttributes(
LPVOID lpvAddress,
DWORD cbSize,
DWORD dwNewFlags,
DWORD dwMask,
LPDWORD lpdwOldFlags
);
Parameters
lpvAddress
[in] The start address of the virtual memory to be changed.

cbSize
[in] The length, in bytes, of the virtual memory to be changed.

dwNewFlags
[in] Specifies the new value of the bits to be set.

dwMask
[in] Specifies which bits are to be changed.

lpdwOldFlags
[in] If this parameter is not NULL, *lpdwOldFlags contains the original value of the page entry of the first page upon return.

Return Value
TRUE indicates success. FALSE indicates failure.

Remarks
The dwMask parameter specifies the bits to be changed. For example, if the original value is 0x00100010, dwMask is set to 0x30, and dwNewFlags is set to 0x030, the new value will be 0x00100030. The new value is calculated using the following formula:

newValue = (oldValue & ~dwMask)|(dwNewFlags & dwMask);
If dwMask is set to zero, it behaves like a query function. This means that nothing is changed, and the original page entry is returned through lpdwOldFlags.

Note:
Do not change the physical page number, which includes bits 10 through 31 for most CPUs. Otherwise, it causes unexpected system behavior.
The VirtualSetAttributes function changes the translation look-aside buffer (TLB) entry directly. The calling function should be aware of what CPU architecture it is running on and which attributes to change.

The VirtualSetAttributes function can be used on the x86 and XScale microprocessors to speed up the display buffer.

The VirtualSetAttributes function does not work on SHx processors.

Requirements
Header pkfuncs.h
Library coredll.lib
Windows Embedded CE Windows CE .NET 4.1 and later

---------- Post added at 09:52 PM ---------- Previous post was at 09:24 PM ----------

http://www.e-consystems.com/WindowsCE5vs6.asp

Thanks Spavlin...

I'm looking at using CeVirtualSharedAlloc to let me re-implement SetKMode. The problem is that all these functions can only be called *from* kernel mode, so I need to use the HtcUtility driver to overwrite the process's stored registers - specifically, the flag register that controls the processor mode.

*LocalAllocInProcess
This is no longer supported. One possible alternative is to use remote heap mechanism to share heap data.
*LocalFreeInProcess
This is no longer supported. One possible alternative is to use remote heap mechanism to share heap data.
*LocalSizeInProcess
This is no longer supported. One possible alternative is to use remote heap mechanism to share heap data.
*DumpKCallProfile
This is no longer supported. API call is a no-op.
*ProfileSyscall
This is no longer supported. API call is a no-op.
*AddTrackedItem
This is no longer supported. API call will return failure. Use Application Verifier to track heap memory.
*DeleteTrackedItem
This is no longer supported. API call will return failure. Use Application Verifier to track heap memory.
*PrintTrackedItem
This is no longer supported. API call will return failure. Use Application Verifier to track heap memory.
*RegisterTrackedItem
This is no longer supported. API call will return failure. Use Application Verifier to track heap memory.
*FilterTrackedItem
This is no longer supported. API call is a no-op. Use Application Verifier to track heap memory.
*MapPtrToProcess
This is no longer supported. If this is being used to access an API argument, you can remove the mapping call. If this is
being used to access a pointer that is passed inside a structure or through some other means, you would need to explicitly switch to calling
buffer marshalling and unmarshalling APIs.
*MapPtrUnsecure
This is no longer supported. If this is being used to access an API argument, you can remove the mapping call. If this is
being used to access a pointer that is passed inside a structure or through some other means, you would need to explicitly switch to calling
buffer marshalling and unmarshalling APIs.
*GetProcFromPtr
This is no longer supported. Use OpenProcess API to get a process handle.
*GetProcAddrBits
This is no longer supported. Process VMBase is always at the same fixed location (64K).
*SetProcPermissions
Completely impossible, remove it. Likely this call wraps code that accesses another process virtual memory space;
verify that the addresses youre using are now getting duplicated / aliased for you, or else you will need to do so yourself.
*GetCurrentPermissions
Completely impossible, remove it. Likely this call wraps code that accesses another process virtual memory space;
verify that the addresses youre using are now getting duplicated / aliased for you, or else you will need to do so yourself.
*SetHandleOwner
Update code to use DuplicateHandle to create a new handle for the other process, and then close the original handle. Also,
if your code is part of a kernel-mode server, you need to move the ownership assignment out into the external method that is only invoked
when your API is called by a different process.
*SetKMode
Completely impossible, remove it. Likely this call wraps code that accesses another process virtual memory space; verify that the
addresses youre using are now getting duplicated / aliased for you, or else you will need to do so yourself.
*ConnectDebugger
This is no longer supported.
*GetProcessIndexFromID
This is no longer supported. If this API is being used to implement process reference counting, you should revise
your reference counting to track processes in a linked list instead of an array.
*GetCallerProcessIndex
This is no longer supported. If this API is being used to implement process reference counting, you should revise
your reference counting to track processes in a linked list instead of an array.
*FlushViewOfFileMaybe
This is no longer supported.
*CeGetCurrentTrust
Trust/Untrusted mechanism doesn't exist anymore. One can limit the code which runs on the system by using certmod component.
*CeGetCallerTrust
Trust/Untrusted mechanism doesn't exist anymore. One can limit the code which runs on the system by using certmod component.
*CeMapArgumentArray
This is no longer supported.
*MapCallerPtr
This is no longer supported. If this is being used to access an API argument, you can remove the mapping call. If this is
being used to access a pointer that is passed inside a structure or through some other means, you would need to explicitly switch to calling
buffer marshalling and unmarshalling APIs.
*MapPtrToProcWithSize
This is no longer supported. If this is being used to access an API argument, you can remove the mapping call. If this
is being used to access a pointer that is passed inside a structure or through some other means, you would need to explicitly switch to calling
buffer marshalling and unmarshalling APIs.
*RemoteHeapAlloc
This is no longer supported. Use the new remote heap mechanism (API CeRemoteHeapCreate) to share heap data.
*RemoteHeapReAlloc
This is no longer supported. Use the new remote heap mechanism (API CeRemoteHeapCreate) to share heap data.
*RemoteHeapFree
This is no longer supported. Use the new remote heap mechanism (API CeRemoteHeapCreate) to share heap data.
*RemoteHeapSize
This is no longer supported. Use the new remote heap mechanism (API CeRemoteHeapCreate) to share heap data.
*GetProcessIDFromIndex
This is no longer supported.
*CeZeroPointer
This is no longer supported.
*ConnectHdstub
This is no longer supported.
*ConnectOsAxsT0
This is no longer supported.
*ConnectOsAxsT1
This is no longer supported.
*AttachHdstub
This is no longer supported.
*AttachOsAxsT0
This is no longer supported.
*AttachOsAxsT1
This is no longer supported.
*CeGetProcessTrust
Trust/Untrusted mechanism doesn't exist anymore. One can limit the code which runs on the system by using certmod component.

/PSLNotify//RemoteLocalAlloc//RemoteLocalReAlloc//RemoteLocalSize//RemoteLocalFree/
/ForcePageout//GetRomFileInfo//GetRomFileBytes//GetKPhys//GiveKPhys/
/StringCompress//StringDecompress//BinaryCompress//BinaryDecompress/
/GetFSHeapInfo//SetLowestScheduledPriority//PowerOffSystem/
This API can only be called from kernel mode code.

/InterruptInitialize//InterruptDone//InterruptDisable/
This API can only be called from kernel mode code or from user mode drivers.

/SetPowerOffHandler//SetGwesPowerHandler//SetHardwareWatch//ReadRegistryFromOEM/
/WriteRegistryToOEM//LockPages//UnlockPages//SetRAMMode//SetStoreQueueBase//PerformCallBack4/
/VirtualSetAttributes//DecompressBinaryBlock/
/PageOutModule//CeVirtualSharedAlloc//CeCreateToken/
This API can only be called from kernel mode code.


/LoadIntChainHandler//FreeIntChainHandler//CreateStaticMapping//InterruptMask/
This API can only be called from kernel mode code or from user mode drivers.


IsAPIReady
Usage discouraged. We expanded the number of API sets and
changed the API set IDs. Use WaitForAPIReady API or use ready event
signaling mechanism.
RegisterDevice
Usage discouraged. Use ActivateDeviceEx instead.
DeregisterDevice
Usage discouraged. Use DeactivateDevice instead.
VirtualProtect
This API can only be called on an address previously allocated through VirtualAlloc in the caller's process space.
CreateFileForMapping
Usage of this API is discouraged. You should consider switching to CreateFile and CreateFileMapping. (Please note
that the handle-closing semantics for CreateFile are different from those of CreateFileForMapping: the kernel automatically closes the
handle you receive from CreateFileForMapping, while you must close the handle you receive from CreateFile.)
VirtualCopy
This API can only be used to alias in the current active process. For kernel mode threads, one can use the new API VirtualCopyEx
to create an alias of virtual address between two different processes. Also if you are using this API to access hardware directly, then you
need to run your code in a kernel mode driver.
CreateAPISet
New function descriptors are required.
GetCallerProcess
Usage discouraged. Use GetDirectCallerProcessId or GetCallerVMProcessId instead.
RegisterAPISet
New function descriptors are required.
CreateFileForMappingW
Usage of this API is discouraged. You should consider switching to CreateFile. (Please note that the handle-closing
semantics for CreateFile are different from those of CreateFileForMapping: the kernel automatically closes the handle you
receive from CreateFileForMapping, while you must close the handle you receive from CreateFile.)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ActivateDevice
Driver load flags have changed to account for kernel mode and user mode srivers.
ActivateDeviceEx
Driver load flags have changed to account for kernel mode and user mode srivers.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ServiceIoControl
Service handles are no longer exposed to applications - applications always deal with filesystem based handles now. Replace
these calls with DeviceIoControl instead.
GetServiceHandle
Use of this API will leak a file handle since internally this is now implemented as CreateFile and there is no
CloseServiceHandle API call; new code should not use this.[COLOR="Silver"]