Add missing Windows API functions #139

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
2 participants

This pull request adds several functions, structures and constants that are missing from core.sys.windows.windows, all of them related to the creation and management of windows and class windows.

It's very difficult to program Windows GUI apps using the aforementioned module. One has to either roll its own definitions, or use an external solution. This is an attempt palliate some of the more glaring omissions.

Note: This pull just contains additions for basic Windows management, it doesn't update the (also incomplete) definitions for controls (Edit, ListView, ComboBox, etc.) and is compatible with Windows 2000 and newer versions.

I would like to add that I know that there's has been discussion about adding the Win32 bindings to druntime. This is just a stopgap solution while that situation is resolved.

@jmdavis jmdavis and 1 other commented on an outdated diff Jan 25, 2012

src/core/sys/windows/windows.d
@@ -1830,8 +1853,376 @@ enum
DCX_VALIDATE = 0x00200000,
}
+struct ALTTABINFO
+{
+ DWORD cbSize;
+ int cItems;
+ int cColumns;
+ int cRows;
+ int iColFocus;
+ int iRowFocus;
+ int cxItem;
+ int cyItem;
+ POINT ptStart;
+}
+alias ALTTABINFO* PALTTABINFO, LPALTTABINFO;
+
+struct GUITHREADINFO // Windows 2000
@jmdavis

jmdavis Jan 25, 2012

Member

Windows 2000? Meaning that it was added with Windows 2000? If so, I'm not sure how relevant that is. Anyone developing with the Windows functions is going to have to look them up on MSDN anyway, so if that's what the comment means, it doesn't seem particularly helpful to me. And if that's not what it means, I have no idea what it means.

@YaoGomez

YaoGomez Jan 25, 2012

This means that, according to the MinGW, the Win32 D bindings and some old MSDN documentation, those structs and functions where defined or declared for the first time in Windows 2000. It's mostly an internal flag, to identify those symbols that could be, in theory, not defined on some of the ancient DMD window libs.

@jmdavis

jmdavis Jan 25, 2012

Member

From what I understand, what MSDN says on that isn't even necessarily correct. It lists stuff as being from Win2K which actually predates it. And it looks like we're going to be removing support of pre-Win2K from druntime and Phobos, so there's no need for the "Windows 2000" comments.

@YaoGomez

YaoGomez Jan 25, 2012

OK. I'll remove them. Maybe I'm just too paranoid with this. I had a bad experience with some of the windows libs bundled with DMD. A GDI function that was from Windows 98 was undefined in the gdi32.lib from DMD! And that was maybe two years ago.

@jmdavis

jmdavis Jan 25, 2012

Member

Well, I can't vouch for how well the Windows libraries bundled with dmd are, but if it's missing functions form Windows 98, keeping track of what's in Windows 2000 won't help any. It sounds more like some functions were just missed, and if that's the case, who knows whether it's systematic or not, let alone whether it has anything to do with the Windows version.

@jmdavis jmdavis commented on the diff Jan 25, 2012

src/core/sys/windows/windows.d
+enum
+{
+ STATE_SYSTEM_FOCUSABLE = 0x00100000,
+ STATE_SYSTEM_INVISIBLE = 0x00008000,
+ STATE_SYSTEM_OFFSCREEN = 0x00010000,
+ STATE_SYSTEM_UNAVAILABLE = 0x00000001,
+ STATE_SYSTEM_PRESSED = 0x00000008
+}
+
+struct TITLEBARINFO
+{
+ DWORD cbSize;
+ RECT rcTitleBar;
+ DWORD rgstate[CCHILDREN_TITLEBAR + 1];
+}
+alias TITLEBARINFO* PTITLEBARINFO, LPTITLEBARINFO;
@jmdavis

jmdavis Jan 25, 2012

Member

I'd argue that you shouldn't have multiple aliases on the same line. They're too easy to misread that way.

@YaoGomez

YaoGomez Jan 25, 2012

I just followed the same style that Walter used in that module. Look some of the older, struct definitions and they follow the same pattern. It's almost always aliases to pointers, most of them are from that time when you had to worry for long and near pointers.

I think that having the aliases in several lines would mean more wasted, vertical space, but if you think that it should be that way, I can make those changes.

@jmdavis

jmdavis Jan 25, 2012

Member

There's no requirement that they be on separate lines, and if other aliases in the same module use that pattern, then at least it's consistent. I just don't personally like that style. I think that it harms code readibility.

@jmdavis jmdavis commented on the diff Jan 25, 2012

src/core/sys/windows/windows.d
@@ -2345,6 +2772,7 @@ enum : HWND
}
export ATOM RegisterClassA(WNDCLASSA *lpWndClass);
+export ATOM RegisterClassW(WNDCLASSW *lpWndClass);
@jmdavis

jmdavis Jan 25, 2012

Member

Please make sure that the asterisks are next to the type with pointers. Unlike with C, they go with the type, not the variable.

@YaoGomez

YaoGomez Jan 25, 2012

Point taken, I'll do it. Thanks.

Member

jmdavis commented Jan 25, 2012

Are these all from the same Win32 library? If there are enough of them, it starts looking desirable to split them up, though they would ideally follow the same organization that they do in the Win32 libraries.

Yes, they are all from the winuser.h file. The lib is user32.lib, I think. And yes, I agree that the windows.d module should be splitted in smaller chunks. But if we follow the Windows SDK/MinGW file organization, and if we are aiming for completeness, then that would mean to create hundreds of new modules. Just take a look at the Win32 bindings project. That's the size of this monster.

Wouldn't be better to include that project as the default windows modules for Phobos?

Another alternative would be to use a different approach. Maybe using as te layout/organization how the API is defined on the libraries (kernel, gdi, user, shell, etc.)?

Member

jmdavis commented Jan 25, 2012

The typical approach with OS APIs has been to put them in druntime, but with the sheer size of the Windows API, I don't know if that will be acceptable or not. Regardless, I would think that we'd want them all eventually and that we'd want the organized however they're organized in the Win32 API itself (since that's how we've generally been organizing the OS APIs) - and if that means hundreds of modules, then that means hundreds of modules. But regardless, it requires figuring out where they should be going, and that's going to require further discussion.

Yes. But what should we do in the interim? I mean there's the need right now of more complete Windows API modules. Well, I hope that soon this project could gain some traction. I'll stick to defining my own modules (or use the dsource.org ones).

So, should I close this pull request? Or do I make the changes that you indicated?

Member

jmdavis commented Jan 25, 2012

I'm not sure that we shouldn't merge this, but we do need a more longterm plan. I'll bring it up for discussion in the newsgroup.

Member

jmdavis commented Jan 26, 2012

Okay. We can merge this in, but I think that the best approach would be to just take the Win32 Bindings project and merge it into druntime. I'm not sure what rearranging that would require (since I've never used it), but my guess would be that for the most part, the stuff currently sitting in core.sys.windows would be in other modules, so putting a bunch of new stuff in core.sys.windows right now doesn't seem like a great idea unless it's going to be a long time before someone creates a pull request for the full bindings.

Are you willing to take the time to create a pull request with the full bindings, or do we need to find someone else who's willing to do so?

I could do it. Yes. But bear in mind that this job it's going to take its time anyways. Even if we go ahead an start this, we need to discuss several issues that could potentially arise from this task. For starters the Win32 bindings use a versioning system with constants and static ifs, (paralelling the way the original Windows API uses #defines all the way)and some of them must be defined even before using them.

Besides, this project supports both D1 and D2, so there are some (templated) tricks that used across all modules to deal with both strings and constant differences between both versions, so this also should be a theme of discussion.

There's also the (potential) bloat that could be incurred with so much code. Remember that DMD isn't that good eliminating unused code from object files and executables.

I can volunteer to do this. But my time is limited and I could dedicate a few hours a day and maybe more at weekends. But first I strongly suggest that all this (and more) issues should be discussed and decided even before starting.

So, what should we do about this pull? Should I close it?

Member

jmdavis commented Jan 27, 2012

I think that it's farily clear at this point that we should be putting the Win32 API bindings in druntime, and if that's a lot of symbols, then that's a lot of symbols. dmd can improve at removing unused symbols in the future. And it's only declarations, not definitions, as far as functions go, which definitely reduces the bloat.

Exactly what the best way to handle the versioning in that code is, I don't know, because I'm not at all familiar with it. Any issues with that can (and probably should) be brought up in the newsgroup.

If you're willing to take the type to the time to port the Win32 API project's bindings to druntime, that would be great. If it takes you a while, that's fine as long as we're talking months rather than years. Most stuff for druntime and Phobos gets done by folks in their free time and often takes months. If you have any issues, bring them up in the newsgroup. And if you can't do it, then we probably need to bring it up in the newsgroup so that we can get someone else to do it.

As for this pull request, I'll close it. Unless these bindings are specifically required for druntime or Phobos for some reason, I don't see much point in adding them when they'll just be superceded when the full bindings get merged in. Windows programmers are often already forced to use the Win32 Bindings project anyway, so all these bindings would do is slightly reduce the problem. They can be added in the correct place with all of the other bindings when the full bindings are merged in.

jmdavis closed this Jan 27, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment