[tomasz86]

EDIT: From this moment all information about everything I do will be available here & here.

EDIT: There was a small bug in BETA5. Please use BETA5a instead.

I've prepared a BETA5 of Unofficial Updates Rollup. I've only fixed some bugs. This one is very likely to be the final version.


Windows2000-UURollup-BETA5a-x86-Global.exe (20 MB)

This post has been edited by tomasz86: 23 March 2012 - 07:41 AM

[blackwingcat]

msvcrt.dll (VC6 Runtime) compatible to Windows XP/2003.
I use in KDW msvcrt changed a little change from 2003's one.

Lastest DBGHELP.DLL is included in last SDK, and it is Advanced compatible to XP7s one.
Almost game installers include it.

CryptStringToBinaryA/W
WIndows 2000 has native both functions.
Plz see offcet 00072180 and 0007232A (5.131.2195.7147)

MacLover, on 19 October 2011 - 03:25 PM, said:

I just finished going through all of the files for VS2008 and found that the following APIs are needed to run it:

MSVCRT.DLL -> _vscwprintf (WIC)
MSVCRT.DLL -> _wtof (WIC, WPF)
MSVCRT.DLL -> _aligned_free (WIC)
MSVCRT.DLL -> _aligned_malloc (WIC)
MSVCRT.DLL -> ___lc_codepage_func (WPF, XPS)
MSVCRT.DLL -> ___lc_handle_func (WPF, XPS)
MSVCRT.DLL -> __uncaught_exception (WPF, XPS)
MSVCRT.DLL -> _resetstkoflw (WPF)
MSVCRT.DLL -> __crtGetStringTypeW (XPS)
MSVCRT.DLL -> __crtLCMapStringW (XPS)
MSVCRT.DLL -> ___mb_cur_max_func (XPS)
MSVCRT.DLL -> __pctype_func (XPS)
MSVCRT.DLL -> _strtoi64 (XPS)
MSVCRT.DLL -> _strtoui64 (XPS)

DBGHELP.DLL -> SymLoadModuleEx
DBGHELP.DLL -> SymEnumTypes
DBGHELP.DLL -> SymGetTypeInfo

CRYPT32.DLL -> CryptStringToBinaryA
CRYPT32.DLL -> CryptStringToBinaryW

[WildBill]

Hey all, just a little news update...

I've finished rewriting csrsrv in VS2005 for KB2393802 v9 and it's working well. I've significantly hardened it against attack and fixed what I think are several bugs in the original. I could take the hardening approach one step farther, but I haven't decided to do it yet as it would be pretty paranoid. I also think I've fixed the crash issue in the UP PAE kernel (ntkrnlpa.exe). Unfortunately (or fortunately, depending on how you look at it) I;m seeing that the SxS messages that my upgraded kernel32 is generating are getting lost in basesrv.dll (which csrsrv loads). The easiest thing to do is going to be to rewrite basesrv as well, which I think will be a lot easier since it's a lot smaller than csrsrv and now I have a starting codebase to work with. I'm still working nearly every day on KB2393802 v9 and I'm bound and determined to finish it.

I've put in doxygen comments for all of the routines in my csrsrv, but not yet for variables, types, etc. I'm not sure that it's really necessary as they're pretty self-explanatory. If people wish I can post the sources for it in the meantime in case anyone wants to improve on it.

[tomasz86]

@WildBill

The ole32.dll 5.0.2195.7060 from your 979687 seems to be buggy. Please check this and the following post.

This post has been edited by tomasz86: 03 April 2012 - 02:59 AM

[WildBill]

(sigh)

Sometimes I wonder why I put myself through this...

I've completely rewritten csrsrv.dll and basesrv.dll in C and I've significantly hardened them against attack. Then I figured it would be straightforward to update kernel32.dll to finish KB2393802-v9. But nooo..... for some reason I just can't make it work at the assembler level, partially because I can't trace its progress. So I decided to bite the mother-of-all-bullets...rewrite kernel32.dll in C as well.

In 5 days I've implemented 329 exported functions out of about 850, though the pace will slow down as the remaining ones become more and more complex. Nevertheless, it's proving to be a much simpler process than rewriting csrsrv and basesrv -- mainly because kernel32 apparently doesn't really do all that much: it farms out the heavy lifting to csrsrv, basesrv, winsrv, and ntdll and is mostly just a wrapper for those DLL's. So this mainly an exercise of cranking the handle by examining each function in IDA's decompiler and implementing a version that VS2005 can digest. In some cases IDA produces code that is pretty convoluted and I have to do some rewriting, but so far it's not nearly as bad as it was for csrsrv and basesrv -- the code in kernel32 just isn't that complex.

I'm hoping that this will be the last DLL I have to rewrite to get the patch working, since there isn't that much involved in getting SxS support going, and I've already done all the kernel-side stuff. The big unknown will be making sxs.dll happy, though I don't expect to have to rewrite it, just include it.

[WildBill]

I've posted KB2393802-v9

It doesn't include the new rewritten stuff and is mostly a bugfix version. It adds several SxS API's to ntdll, but until the rest of the pieces are added to kernel32 they won't do anything (they should be safe to call, they'll just return error codes since they won't succeed). I still recommend it though as it fixes several bugs in -v8.

Now I can work on finishing SxS support for v10 without having those bugs hanging over my head...

This post has been edited by WildBill: 14 May 2012 - 01:24 PM

[tomasz86]

Thanks WildBill

By the way, here is a slimmed down version of the update.inf for KB2393802-v9. All useless sections and lines have been removed so it's much easier to navigate.

Attached File(s)

•  update.inf (3.96K)
  Number of downloads: 7

This post has been edited by tomasz86: 14 May 2012 - 03:33 PM

[tomasz86]

These APIs are present in BWC kernel's kernel32.dll and are not included in yours:

ActivateActCtx
CheckRemoteDebuggerPresent
CreateActCtxA
CreateActCtxW
DeactivateActCtx
GetGeoInfoA
GetGeoInfoW
GetUserGeoID
ReleaseActCtx
WTSGetActiveConsoleSessionId

Would it be difficult to add them in the future version, especially the ones which have sth to do with ActCtx, i.e. ActivateActCtx, CreateActCtxA, CreateActCtxW, DeactivateActCtx & ReleaseActCtx? They help fix a lot of dependencies and also make it possible to use uxtheme.dll directly from %systemroot%\system32. Without these dependencies there are problems with .NET Framework (when uxtheme.dll is present in the system, that is).

This post has been edited by tomasz86: 14 May 2012 - 04:24 PM

[WildBill]

The ActCtx API's are the ones I've been working on since November, but I'm finding that I need them to actually work or apps like Adobe Reader crash.

[piotrhn]

In KB2393802-v9 fixed error with boot.ini->/PAE, now works ok without BSOD.

Thanks WildBill

[blackwingcat]

Hi,

Pe Tool v0.05 Seems to make broken out export table offset +0xc.
for example. Load hal.dll and save it. The name pointer is indicated "L.DLL"

[WildBill]

kernel32.dll rewrite status: NLS Hell ™.

468 exported functions implemented out of a total of about 902

I'm currently bogged down in the NLS support -- apparently kernel32 does all the heavy lifting for localized data (date/time formats, etc.). I'm having to reverse-engineer a bunch of structures, and in the process the format of the various .nls files in system32. I now know all about Japanese emperor eras, how to convert numbers to Hebrew numbers (including the special cases for 15 and 16 and the reason behind them), and creating Hebrew and Hijiri dates. I've completely reverse-engineered locale.nls (and documented it to the nth-power in my kernel32.h) and partially reverse-engineered ctype.nls and unicode.nls. I've even had to write a Java program that dumps out all the info in locale.nls.

(sigh)

This post has been edited by WildBill: Yesterday, 09:28 PM