While researching for a book that I am writing , I came across this-

"Some malware goes so far as to avoid importing any functions from available
DLLs. Instead, it emulates all of the APIs it needs. This means that you cannot list the
functions, so you cannot easily set breakpoints on them, as all API calls will just be
a part of the malware code.In some cases, malware authors even use this to trap reverse engineers: they
may import functions that are never used (having used the emulated ones instead)."

Now my question is-

How can I write win32 api without using win32 or native api. For example, How can I write code that'll manipulate windows registry without using win32 or native api?

or if you've heard of any virus that emulates API, give me its name. The rest (like, retrieving the API emulating code from the virus) I'll manage.

Take a look at the functions themselves in a debugger. The typical WinAPI export will call some internal functions, eventually boiling down to a system call or two. The specs for these kernel transitions are undocumented on the whole, but if you can emulate the code then you can emulate the API. Is there anything specific you were planning on doing?

The win32api is built on top of the native API (aka syscalls) -- there is no way you can emulate that work without eventually doing a system call -- all work the OS does must eventually go through the kernel -- especially something as critical as accessing the registry, which is shared by potentially hundreds of threads on the system.

sure, for some api's you cant do it without system call, other api's you can... no problems
for example - lstrlen and so on can be done without api...

Sure, MSVC will actually inline the call anyway.

But think of the context -- this is malware.

I'd love to see malware that does no I/O

while (TRUE); ?

Just my ignorant contribution here.

If you (the malware, or protection author) decided to forgo the use of winAPI in order to avoid detection, breakpoints, reversibility in general, you pay the price in at least two fronts:
Universality: Windows API take care to make all the adaptation between the abstract layer of software and the real layer of hardware. If you renounce to using API's, your software/malware will only run a subset of machines. If you decided to code 'down to the bared metal', all the commodity of abstraction layers is gone for you, ergo, your code will only run in systems that are srtuctured like your own, unless you are willing to re-invent the wheel and emulate all possible hardware configurations that get to interact with your code.
The second front is related to the first: There is no a priori reason why you cannot write an ad-hoc API set to read and write to the registry: After all, the registry is only a file, bytes on a disk, with a predefined structure.

But your ad-hoc API has to reinvent the wheel: from reading raw data from disk (to avoid permission hurdles from the OS), understand the structure of the registry database, reverse engineer how to insert or delete keys into a database, which is, using winAPI, high level stuff, but actual bytes into a stream, low level stuff that you have to manage to do without corrupting the whole structure, and keep it up to date with un-documented changes and updates.
Impossible? not.
cumbersome and impracticable: You bet.

There is a very good reason why you can't read raw data from the disk:

This isn't DOS anymore!

You can't just issue interrupts from Ring 3 (user-mode) to read from the hard-drive. You can't do DMA, you can't can't access I/O ports.

The *only* way for you to read raw data from the disk, is to use CreateFile and open a handle to the raw drive (guess what: that's a system call) and then issue IOCTLs to the disk driver (more system calls!). Even worse, Vista blocks raw disk access, even if you're administrator (and with UAC, you'll get an elevation prompt just to try opening the disk for raw access).

I could go on with even more reasons why this is won't work (including the effects of you modifying the registry behind everyone's back -- you won't be able to make atomic modifications from user-mode, and you're likely 99.9% sure to trip up some consistency check). But there's no point in discussing that because of the initial problem: you won't get raw disk access without system calls and admin access. The former defeats the purpose of the request