It isn't a dumb question. I believe the reason is the following:

Leading up to any Windows release, Microsoft has a whole bunch of teams working on different features. Some of those features make it into the release, other features don't make it and get cut. What sometimes happens, is that a feature makes it in, but then problems are discovered in testing, and it gets pulled out again at the last minute. When a feature is removed late in the game like that, it is desired to take the lowest risk removal mechanism as possible–one way of doing that is to actually leave the feature in the code, but leave it undocumented, and hope nobody discovers it and uses it (an approach avoided nowadays due to the risk of exploitable security bugs in the buggy API, but in the past it was more common). Another way is to leave its APIs in-place, and either stub out their implementations (to always return an error), or even hide the actual implementation behind a #define that is turned off in the shipping copy. That way, you avoid making any changes to DLL export tables, the system call table, etc., which you worry (even just out of an abundance of caution) might have some downstream negative effect, but also don't have to worry about anyone discovering the broken feature and trying to use it. Then, in the next release, you have a choice – sometimes they will fix the issues with the feature and put it back in, other times priorities have changed and the remnants of the feature (such as API stubs) get removed altogether. That is why sometimes Windows DLLs export undocumented APIs that don't do anything.

(I've never worked for Microsoft, so this is not based on any internal info, just an inference from observing how Microsoft and other vendors do things.)

Could you give an example? I don't see anything that's on Vista SP1 but not on SP2.

Sorry, in my case I saw this on SP0 not SP1: NtListTransactions

that's probably part of TxF (aka transactional ntfs) which got deprecated basically as soon as it was released (though i think it's still used internally for e.g. system restore) so it's likely that got moved around somehow or the TxF API got reimplemented in userspace

I don't believe their deprecation claims on that. It's too deeply ingrained into the OS for them to ever remove it, and too useful and difficult to replace. Really, it just doesn't have enough users, is all. And there's more to transactions than just the file system (TxF) so I'm not even sure it's related to this either.

Also you can't implement TxF in userspace. It has to detect conflicts with other applications and roll back in the case of an unsuccessful commit (power loss etc.) before the file system is used again. Any userspace implementation would leave stuff in a corrupted state until it's re-run.

> I don't believe their deprecation claims on that.

I don't either, although the API is kind of overkill for most use cases so I'm not too surprised they discourage people from using it.

> And there's more to transactions than just the file system (TxF) so I'm not even sure it's related to this either.

True, I just assumed it was related to the txfs_list_transactions ioctl.

> Also you can't implement TxF in userspace. It has to detect conflicts with other applications and […]

I think the Kernel Transaction Manager already takes care of that. I think??? TxF could be implemented as a userspace library on top of KTM, but I'm not particularly familiar with either facility. Though if it was possible perhaps they would've done it that way in the first place, since TxF uses KTM regardless.

I wonder what did happen to it between SP0 and SP1.

I don't know what it does (seems it was never documented? possibly so it could be removed), but for example, I do see NtEnumerateTransactionObject, which may have overlapped with its functionality? Or maybe NtQuerySystemInformation or another function does similarly.

i would suspect a brand new idea [thus not appearing earlier] lost traction or relevence and didnt make the cut to migrate into the next revision