Isn't this Bad Coupling?

[MrBeans]

Hello Everyone,
I got a question regarding Software design of Windows and thought we could discuss on this.

User32.dll closely depends on Gdi32.dll and vice-versa, Isn't this an example of Bad Coupling?

[Skizmo]

yes it is.

[cilu]

But who said Windows or particular parts of it are a good examples of software design? I think mostly, it was supposed to work.

[MrBeans]

yes it is.

But who said Windows or particular parts of it are a good examples of software design? I think mostly, it was supposed to work.

So what do you think the solution to this particular problem would be? How do you think User32.dll and Gdi32.dll could be seperated so as to have lowest possible coupling? What could be a better example in terms of Software Design?

[Krishnaa]

No, because it's not an OOP design, plus those are very much low level OS DLLs and there OOP does not apply that tightly.

[Krishnaa]

But who said Windows or particular parts of it are a good examples of software design? I think mostly, it was supposed to work.

Good one !

BTW I would say it's a little diff design, they have done a very good job at modularization.

[Skizmo]

No, because it's not an OOP design, plus those are very much low level OS DLLs and there OOP does not apply that tightly.

Not entirely true. OO is a way of thinking... it can be applied to every level of programming.

[Arjay]

Not entirely true. OO is a way of thinking... it can be applied to every level of programming.

These designs started way before C++ can popular. At that time, I'm not sure C++ would have been a good choice for the OS. Imagine forcing everyone to recompile their apps because the name mangling changed between compiler versions? Any windowed app is going to load by these dlls anyway (because funtionality from both is required) so if each borrow from the other it isn't a bit deal in the pre-OO age that the system was designed in.

[kirants]

User32.dll closely depends on Gdi32.dll and vice-versa, Isn't this an example of Bad Coupling?

What exactly do you mean ? An example would be good.
As far as I see, user32 and gdi32 dll are just components, and their being dependent on each other is not really an indication of bad coupling when we talk in terms of software components as abstract entities ( dlls being only the implementation details )

[Skizmo]

These designs started way before C++ can popular.

true.

OO was invented after the start of Windows, and redesigning everything would be a hell of a job, and would be NO pfun for the programmers. I only wanted to state that it is possible with the current way of thinking on OO to apply it on EVERY level of programming. It doesn't matter if you are programming GUI, middleware, or even low-level embedded driver stuff. OO can be applied to everything.

[Arjay]

True. I prefer to take a practical approach to designing. Give it your best shot, make the design, revise the design and then move on.

No matter what you design with the advances of the industry, there are going to be better ways in a few years.

Look at MFC. Sure the straight Win32 guys always criticize it, but it obviously has advantages over hand written Win32 code. But when you look at it, MFC was created well before templates came out, so in this day and age its design could certainly be improved with newer capabilities and design patterns.

[Igor Vartanov]

Hello Everyone,
I got a question regarding Software design of Windows and thought we could discuss on this.

User32.dll closely depends on Gdi32.dll and vice-versa, Isn't this an example of Bad Coupling?

Closely depends, you say...

Let's see what that "close dependence" is. This is the list of functions that GDI32.DLL imports from USER32.DLL.

10 entries
CharUpperBuffA
GetAppCompatFlags
GetAppCompatFlags2
GetDC
GetWindowRect
InitializeLpkHooks
IntersectRect
ReleaseDC
UserRealizePalette
wsprintfW

I would note that only GetDC and ReleaseDC seem questionable there.

And this is the list of functions that USER32.DLL imports from GDI32.DLL.

118 entries
bInitSystemAndFontsDirectoriesW
BitBlt
bMakePathNameW
cGetTTFFromFOT
CombineRgn
CopyEnhMetaFileW
CopyMetaFileW
CreateBitmap
CreateBrushIndirect
CreateCompatibleBitmap
CreateCompatibleDC
CreateDCW
CreateDIBitmap
CreateDIBSection
CreateEllipticRgn
CreateFontIndirectW
CreatePalette
CreatePen
CreateRectRgn
CreateRectRgnIndirect
CreateSolidBrush
DeleteDC
DeleteEnhMetaFile
DeleteMetaFile
DeleteObject
Ellipse
EnableEUDC
EnumFontsW
ExcludeClipRect
ExtSelectClipRgn
ExtTextOutA
ExtTextOutW
GdiAddFontResourceW
GdiConvertAndCheckDC
GdiConvertBitmapV5
GdiConvertEnhMetaFile
GdiConvertMetaFilePict
GdiConvertToDevmodeW
GdiCreateLocalEnhMetaFile
GdiCreateLocalMetaFilePict
GdiDllInitialize
GdiFixUpHandle
GdiGetBitmapBitsSize
GdiGetCharDimensions
GdiGetCodePage
GdiPrinterThunk
GdiProcessSetup
GdiReleaseDC
GdiValidateHandle
GetBkColor
GetBkMode
GetBoundsRect
GetCharABCWidthsA
GetCharABCWidthsW
GetCharWidthA
GetCharWidthInfo
GetClipBox
GetClipRgn
GetCurrentObject
GetDeviceCaps
GetDIBColorTable
GetDIBits
GetHFONT
GetLayout
GetMapMode
GetObjectType
GetObjectW
GetPaletteEntries
GetPixel
GetRgnBox
GetStockObject
GetTextAlign
GetTextCharacterExtra
GetTextCharset
GetTextCharsetInfo
GetTextColor
GetTextExtentPointA
GetTextExtentPointW
GetTextFaceAliasW
GetTextFaceW
GetTextMetricsW
GetViewportExtEx
GetViewportOrgEx
GetWindowExtEx
IntersectClipRect
MirrorRgn
OffsetRgn
OffsetWindowOrgEx
PatBlt
PlayEnhMetaFile
PolyPatBlt
QueryFontAssocStatus
RealizePalette
RestoreDC
SaveDC
SelectObject
SelectPalette
SetBitmapBits
SetBkColor
SetBkMode
SetBoundsRect
SetBrushOrgEx
SetDIBits
SetGraphicsMode
SetLayout
SetLayoutWidth
SetPaletteEntries
SetRectRgn
SetStretchBltMode
SetTextAlign
SetTextCharacterExtra
SetTextColor
SetViewportOrgEx
StretchBlt
StretchDIBits
TextOutA
TextOutW
TranslateCharsetInfo

I wonder what exactly did cause your doubts? I can see nothing criminal in this.

Man, actually I wish you the same effectiveness in your DLL interface design.

[MrBeans]

Thanks a lot Igor for dropping in
And thanks for clarifying things

Actually I was more bothered about the dependence of User32.dll on Gdi32.dll.
Somehow I thought that User32.dll being a User Interface dll should not be depending on Gdi32.dll which is an Graphical Interface dll! But then the funny question arises of how User32.dll could communicate with the User without having being able to depict any information.

I got up this doubt while working with a old project where in Data and Drawing were closely coupled in a dll similar to User32.dll, as such there is no problem due to the close coupling but fact is one could not be used independent of the other.

[Igor Vartanov]

Thanks a lot Igor for dropping in
And thanks for clarifying things

Any time, man, any time!

Actually I was more bothered about the dependence of User32.dll on Gdi32.dll.
Somehow I thought that User32.dll being a User Interface dll should not be depending on Gdi32.dll which is an Graphical Interface dll! But then the funny question arises of how User32.dll could communicate with the User without having being able to depict any information.

So now it's clear to you, right? That's good.

In fact, the bad terminology had causing a doubt, as far as I can see. The User Intrface in Windows means nothing but (surprise!) Graphical User Interface. Then how could it be free of using graphical primitives? And GDI exacly is an implementation of that ones. Having this in mind, the forward User32 to GDI32 coupling looks perfectly natural.

More interesting thing must be the backward coupling, but taking a look at the first list of functions, it becomes understood that having its own character, rectangle, string processing in GDI would look ...heh, I dare say, too much academic. As I already said, DC-related entries indeed cause certain doubt about interface design, but having no details about implementation it's hard to become to some definite conclusion.

I got up this doubt while working with a old project where in Data and Drawing were closely coupled in a dll similar to User32.dll, as such there is no problem due to the close coupling but fact is one could not be used independent of the other.

The first point is that User32 is not a pure Data interface but Data+Drawing by definition. And GDI is just a service supporting that drawing part.

The second point - impossibility of independendent use - looks reasonable, because been doing with DCs (GDI32) you always need some window primitives (User32) to be involved, and vice versa. So, I believe, this splicing of the seemingly tightly-dependent code for two modules has been aiming at code modularisation and incapsulation at the most, but not at providing an ability of independent use.