Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WM_SETICON + ICON_BIG: Where is the (handle to the) small icon stored ?
800 views
Skip to first unread message
R.Wieser
May 22, 2013, 5:54:11 AM5/22/13
to
Hello All,
As a kind of continuation of my previous problem I stumbled into this one:
When initializing my app (WM_INITDIALOG) I use LoadIcon to load an
icon-resource containing both 32x32 and 16x16 sub-icons and WM_SETICON +
ICON_BIG to set the 32x32 Alt-Tab icon. For some reason that also causes
the app to display the 16x16 sub-icon at its top-right (system menu). In
itself this is unexpected (and, deanna, not documented. I just re-read the
MSDN page to make sure :-) ), but not bothering me at all.
The question is, how do I retrieve a handle to that small icon (So I can
display it in the SystemTray) ?
I tried GCL_ICONSM as well as WM_GETICON with ICON_SMALL or ICON_SMALL2, but
I either get Zero, or the handle to what appears to be the big icon
(ICON_BIG and ICONS_MALL2 both return the same handle).
Mind you, this is my curiosity speaking as I would like to know how it
works, rather than me looking for a solution. As a working one I isolated
the small icon into its own file and loaded it seperatily (It feels kind of
hackish though ...).
Regards,
Rudy Wieser
As a kind of continuation of my previous problem I stumbled into this one:
When initializing my app (WM_INITDIALOG) I use LoadIcon to load an
icon-resource containing both 32x32 and 16x16 sub-icons and WM_SETICON +
ICON_BIG to set the 32x32 Alt-Tab icon. For some reason that also causes
the app to display the 16x16 sub-icon at its top-right (system menu). In
itself this is unexpected (and, deanna, not documented. I just re-read the
MSDN page to make sure :-) ), but not bothering me at all.
The question is, how do I retrieve a handle to that small icon (So I can
display it in the SystemTray) ?
I tried GCL_ICONSM as well as WM_GETICON with ICON_SMALL or ICON_SMALL2, but
I either get Zero, or the handle to what appears to be the big icon
(ICON_BIG and ICONS_MALL2 both return the same handle).
Mind you, this is my curiosity speaking as I would like to know how it
works, rather than me looking for a solution. As a working one I isolated
the small icon into its own file and loaded it seperatily (It feels kind of
hackish though ...).
Regards,
Rudy Wieser
JJ
May 22, 2013, 2:17:50 PM5/22/13
to
R.Wieser
May 23, 2013, 5:11:58 AM5/23/13
to
Hello JJ,
> Use the LoadImage function and specify the desired icon size.
Yes, that would be another solution. It certainly does away with the
duplicate 16x16 icon in the resource. Thanks for the suggestion.
It however still keeps a duplicate icon in memory (once stored-and-used by
the app, a second one to be displayed in the SysTray)...
-- An update to the test:
The earlier described test was run on a W98se machine. The same test on an
XP machine showed the ICON_BIG and ICON_SMALL2 returning different handles,
with the latter actually holding the 16x16 icon.
Regards,
Rudy Wieser
-- Origional message:
JJ <d...@nah.meh> schreef in berichtnieuws
1dmaaypffsp21.1uv4f5x4rvvfb$.dlg@40tude.net...
> Use the LoadImage function and specify the desired icon size.
duplicate 16x16 icon in the resource. Thanks for the suggestion.
It however still keeps a duplicate icon in memory (once stored-and-used by
the app, a second one to be displayed in the SysTray)...
-- An update to the test:
The earlier described test was run on a W98se machine. The same test on an
XP machine showed the ICON_BIG and ICON_SMALL2 returning different handles,
with the latter actually holding the 16x16 icon.
Regards,
Rudy Wieser
-- Origional message:
JJ <d...@nah.meh> schreef in berichtnieuws
1dmaaypffsp21.1uv4f5x4rvvfb$.dlg@40tude.net...
JJ
May 23, 2013, 10:31:29 PM5/23/13
to
On Thu, 23 May 2013 11:11:58 +0200, R.Wieser wrote:
> Yes, that would be another solution. It certainly does away with the
> duplicate 16x16 icon in the resource. Thanks for the suggestion.
>
> It however still keeps a duplicate icon in memory (once stored-and-used by
> the app, a second one to be displayed in the SysTray)...
>
> -- An update to the test:
> The earlier described test was run on a W98se machine. The same test on an
> XP machine showed the ICON_BIG and ICON_SMALL2 returning different handles,
> with the latter actually holding the 16x16 icon.
>
> Regards,
> Rudy Wieser
I think this depends on the prodived icon dimension, icon image bit depth,
> Yes, that would be another solution. It certainly does away with the
> duplicate 16x16 icon in the resource. Thanks for the suggestion.
>
> It however still keeps a duplicate icon in memory (once stored-and-used by
> the app, a second one to be displayed in the SysTray)...
>
> -- An update to the test:
> The earlier described test was run on a W98se machine. The same test on an
> XP machine showed the ICON_BIG and ICON_SMALL2 returning different handles,
> with the latter actually holding the 16x16 icon.
>
> Regards,
> Rudy Wieser
and the current screen bit depth setting.
I have a Delphi program that has only 32x32x4bit and 16x16x4bit icons. I ran
in under WinXP with 32-bit screen setting. When I check it, both ICON_BIG
and ICON_SMALL returns zero and only ICON_SMALL2 returns a valid handle.
Other program (not mine) which has both 4bit and 8bit icons seems to have
valid handle for both ICON_BIG and ICON_SMALL. It could be that Windows also
accept 8bit icons if the screen setting is 24/32 bit.
R.Wieser
May 24, 2013, 4:21:54 AM5/24/13
to
Hello JJ,
> I have a Delphi program that has only 32x32x4bit and 16x16x4bit icons.
My tests where done with the same kind of icon (colordepth and sizes).
> When I check it, both ICON_BIG and ICON_SMALL returns
> zero and only ICON_SMALL2 returns a valid handle.
In that case do both the top-left of the app and the Alt-Tab show the
correct icons ?
I noticed that when I used WM_SETICON with ICON_SMALL the app showed a
resized 32x32 icon in its upper-left (even though the icon-resource also
contained a 16x16 sub-icon), and the Alt-Tab showed the "have none, I'm
using the default one" icon.
> It could be that Windows also accept 8bit icons if the screen setting is
24/32 bit.
The color-depths of the w98se and XP computers are respectivily 16 and 32
bit, both of which should be enough to display a 16-color (small) icon. In
other words, its possible, but not (logically) likely.
Hmmm ... With the wildly differing results I can't make heads-or-tails from
what is happening ...
Regards,
Rudy Wieser
-- Origional message:
JJ <d...@nah.meh> schreef in berichtnieuws
pimjd1w9oue7$.1nree6i3hkyfv.dlg@40tude.net...
> I have a Delphi program that has only 32x32x4bit and 16x16x4bit icons.
> When I check it, both ICON_BIG and ICON_SMALL returns
> zero and only ICON_SMALL2 returns a valid handle.
correct icons ?
I noticed that when I used WM_SETICON with ICON_SMALL the app showed a
resized 32x32 icon in its upper-left (even though the icon-resource also
contained a 16x16 sub-icon), and the Alt-Tab showed the "have none, I'm
using the default one" icon.
> It could be that Windows also accept 8bit icons if the screen setting is
24/32 bit.
bit, both of which should be enough to display a 16-color (small) icon. In
other words, its possible, but not (logically) likely.
Hmmm ... With the wildly differing results I can't make heads-or-tails from
what is happening ...
Regards,
Rudy Wieser
-- Origional message:
JJ <d...@nah.meh> schreef in berichtnieuws
Paul N
May 24, 2013, 6:36:35 AM5/24/13
to
On May 23, 10:11 am, "R.Wieser" <addr...@not.available> wrote:
> Hello JJ,
>
> > Use the LoadImage function and specify the desired icon size.
>
> Yes, that would be another solution. It certainly does away with the
> duplicate 16x16 icon in the resource. Thanks for the suggestion.
>
> It however still keeps a duplicate icon in memory (once stored-and-used by
> the app, a second one to be displayed in the SysTray)...
>
> -- An update to the test:
> The earlier described test was run on a W98se machine. The same test on an
> XP machine showed the ICON_BIG and ICON_SMALL2 returning different handles,
> with the latter actually holding the 16x16 icon.
>
> Regards,
> Rudy Wieser
>
> -- Origional message:
> JJ <d...@nah.meh> schreef in berichtnieuws
> 1dmaaypffsp21.1uv4f5x4rvvfb$....@40tude.net...
> Hello JJ,
>
> > Use the LoadImage function and specify the desired icon size.
>
> Yes, that would be another solution. It certainly does away with the
> duplicate 16x16 icon in the resource. Thanks for the suggestion.
>
> It however still keeps a duplicate icon in memory (once stored-and-used by
> the app, a second one to be displayed in the SysTray)...
>
> -- An update to the test:
> The earlier described test was run on a W98se machine. The same test on an
> XP machine showed the ICON_BIG and ICON_SMALL2 returning different handles,
> with the latter actually holding the 16x16 icon.
>
> Regards,
> Rudy Wieser
>
> -- Origional message:
> JJ <d...@nah.meh> schreef in berichtnieuws
>
>
>
> > On Wed, 22 May 2013 11:54:11 +0200, R.Wieser wrote:
> > > When initializing my app (WM_INITDIALOG) I use LoadIcon to load an
> > > icon-resource containing both 32x32 and 16x16 sub-icons and WM_SETICON +
> > > ICON_BIG to set the 32x32 Alt-Tab icon. For some reason that also
> causes
> > > the app to display the 16x16 sub-icon at its top-right (system menu).
> In
> > > itself this is unexpected (and, deanna, not documented. I just re-read
> the
> > > MSDN page to make sure :-) ), but not bothering me at all.
>
> > > The question is, how do I retrieve a handle to that small icon (So I can
> > > display it in the SystemTray) ?
>
> > > I tried GCL_ICONSM as well as WM_GETICON with ICON_SMALL or ICON_SMALL2,
> but
> > > I either get Zero, or the handle to what appears to be the big icon
> > > (ICON_BIG and ICONS_MALL2 both return the same handle).
>
> > > Mind you, this is my curiosity speaking as I would like to know how it
> > > works, rather than me looking for a solution. As a working one I
> isolated
> > > the small icon into its own file and loaded it seperatily (It feels kind
> of
> > > hackish though ...).
>
> > Use the LoadImage function and specify the desired icon size.
Hmm, guessing a bit here but...
>
>
> > On Wed, 22 May 2013 11:54:11 +0200, R.Wieser wrote:
> > > When initializing my app (WM_INITDIALOG) I use LoadIcon to load an
> > > icon-resource containing both 32x32 and 16x16 sub-icons and WM_SETICON +
> > > ICON_BIG to set the 32x32 Alt-Tab icon. For some reason that also
> causes
> > > the app to display the 16x16 sub-icon at its top-right (system menu).
> In
> > > itself this is unexpected (and, deanna, not documented. I just re-read
> the
> > > MSDN page to make sure :-) ), but not bothering me at all.
>
> > > The question is, how do I retrieve a handle to that small icon (So I can
> > > display it in the SystemTray) ?
>
> > > I tried GCL_ICONSM as well as WM_GETICON with ICON_SMALL or ICON_SMALL2,
> but
> > > I either get Zero, or the handle to what appears to be the big icon
> > > (ICON_BIG and ICONS_MALL2 both return the same handle).
>
> > > Mind you, this is my curiosity speaking as I would like to know how it
> > > works, rather than me looking for a solution. As a working one I
> isolated
> > > the small icon into its own file and loaded it seperatily (It feels kind
> of
> > > hackish though ...).
>
> > Use the LoadImage function and specify the desired icon size.
According to MSDN, RegisterClassEx was invented to set the small
icons, which could not be set with RegisterClass. And RegisterClassEx
needs at least Windows 2000. So my guess is that W98se does not
actually have "small icons" as such, it is showing a smaller version
of the only icon. Whereas XP etc has both big and small icons which
can be set and inspected separately.
JJ
May 24, 2013, 6:31:48 PM5/24/13
to
On Fri, 24 May 2013 10:21:54 +0200, R.Wieser wrote:
>> When I check it, both ICON_BIG and ICON_SMALL returns
>> zero and only ICON_SMALL2 returns a valid handle.
>
> In that case do both the top-left of the app and the Alt-Tab show the
> correct icons ?
Sorry, my previous inspection was incorrect (was done using external
>> When I check it, both ICON_BIG and ICON_SMALL returns
>> zero and only ICON_SMALL2 returns a valid handle.
>
> In that case do both the top-left of the app and the Alt-Tab show the
> correct icons ?
program).
When I check it directly by debugging, visually, ICON_BIG (on ALT-TAB Task
Switcher) and ICON_SMALL2 (on application window; top-left) are the correct
icon (ICON_SMALL is zero), but they're all auto generated by the system.
Both ICON_BIG and ICON_SMALL2 are 32bit and ICON_SMALL2 dimension is 14x14
instead of 16x16 since my title bar font setting is 8pt (small title bar).
So, ICON_SMALL doesn't seem to be used and loaded since the actual
application window icon dimension is not 16x16 troughout the system
(SM_CXSMICON = 14). I checked each using WM_GETICON, GetIconInfo, then
GetObject.
Regardless, you might want to take a look at ReactOS sources on how it
manage window icons. I may behave the same way as Windows.
JJ
May 24, 2013, 6:40:39 PM5/24/13
to
On Fri, 24 May 2013 03:36:35 -0700 (PDT), Paul N wrote:
> Hmm, guessing a bit here but...
>
> According to MSDN, RegisterClassEx was invented to set the small
> icons, which could not be set with RegisterClass. And RegisterClassEx
> needs at least Windows 2000. So my guess is that W98se does not
> actually have "small icons" as such, it is showing a smaller version
> of the only icon. Whereas XP etc has both big and small icons which
> can be set and inspected separately.
Interestingly, MSDN for VS2008 (October 2007) states that the minimum OS
> Hmm, guessing a bit here but...
>
> According to MSDN, RegisterClassEx was invented to set the small
> icons, which could not be set with RegisterClass. And RegisterClassEx
> needs at least Windows 2000. So my guess is that W98se does not
> actually have "small icons" as such, it is showing a smaller version
> of the only icon. Whereas XP etc has both big and small icons which
> can be set and inspected separately.
requirement for RegisterClassEx is Windows 95 or Windows NT 3.51. The latest
MSDN on the web changed this to Windows 2000 and removed Windows 95.
I'm guessing here also, that this changes is because they want to phase out
old OS support. But I trust the older one because they tend to disclose
information like those in Windows 3 SDK Help file that are still used even
in Windows Blue.
R.Wieser
May 24, 2013, 8:33:29 PM5/24/13
to
Hello Paul,
> According to MSDN, RegisterClassEx was invented to set
> the small icons, which could not be set with RegisterClass.
Actualy, I'm defining a dialog and using it as my main window (using the
DialogBoxParam function). Its definition in a resource-file does not seem
to accept a reference to an icon (I might be wrong there though. If so
please do not hesitate to enlighten
me).
> Whereas XP etc has both big and small icons which can be
> set and inspected separately.
The odd thing is that in both W98se and XP I use the WM_SETICON with
ICON_BIG and get both the Alt-Tab (32x32) as well as the application-icon
(top-left, 16x16) icon set.
In other words: A single setting of an applications icon causes two seperate
sub-icons to be loaded and displayed.
In XP I can retrieve the (16x16) app-icon seperatily (ICON_SMALL2) where in
W98se it just returns the big icon -- even though the app displays the small
icon !
> So my guess is that W98se does not actually have "small icons"
> as such, it is showing a smaller version of the only icon.
:-) I made sure to use an icon-file with both 32x32 and 16x16 sub-icons
that are quite different from each other, and therefore easy to recognise.
Thanks for the your suggestion though.
Regards,
Rudy Wieser
-- Origional message:
Paul N <gw7...@aol.com> schreef in berichtnieuws
7abbaa0d-d08f-4a66...@fv8g2000vbb.googlegroups.com...
> According to MSDN, RegisterClassEx was invented to set
> the small icons, which could not be set with RegisterClass.
DialogBoxParam function). Its definition in a resource-file does not seem
to accept a reference to an icon (I might be wrong there though. If so
please do not hesitate to enlighten
me).
> Whereas XP etc has both big and small icons which can be
> set and inspected separately.
ICON_BIG and get both the Alt-Tab (32x32) as well as the application-icon
(top-left, 16x16) icon set.
In other words: A single setting of an applications icon causes two seperate
sub-icons to be loaded and displayed.
In XP I can retrieve the (16x16) app-icon seperatily (ICON_SMALL2) where in
W98se it just returns the big icon -- even though the app displays the small
icon !
> So my guess is that W98se does not actually have "small icons"
> as such, it is showing a smaller version of the only icon.
that are quite different from each other, and therefore easy to recognise.
Thanks for the your suggestion though.
Regards,
Rudy Wieser
-- Origional message:
7abbaa0d-d08f-4a66...@fv8g2000vbb.googlegroups.com...
R.Wieser
May 24, 2013, 9:07:06 PM5/24/13
to
Hello JJ,
> When I check it directly by debugging, visually, ICON_BIG (on
> ALT-TAB Task Switcher) and ICON_SMALL2 (on application
> window; top-left) are the correct icon (ICON_SMALL is zero),
> but they're all auto generated by the system.
In your case I assume the most apropriate icons for the task are (or should
be?) up- or down-scaled a bit to fit your requirements. With no other data
I assume your "big" icons are near to 32x32 and your small ones near to
16x16. That would (logically) mean that the results would stay the same:
the 32x32 icon-resource for Alt-Tab and the 16x16 icon-resource for the app
itself. Both scaled to match the (a bit) different sizes.
In other words: even if your displays settings are abit different, the
sub-icon usage should still be the same.
So, your ICON_BIG should really return a different result from ICON_SMALL2.
But does it ?
> The latest MSDN on the web changed this to Windows 2000 and
> removed Windows 95.
> I'm guessing here also, that this changes is because they want to
> phase out old OS support
Don't guess, thats exactly what they are doing. Ofcourse, the problem still
exists under XP and later versions, as mentioning DLL version numbers is
simply "not done" (fun when you try to get some info about some
"side-by-side" installations of (different versions of) "the same" DLL).
:-\
Regards,
Rudy Wieser
-- Origional message:
JJ <d...@nah.meh> schreef in berichtnieuws
4rsgv1bcrkvx.s...@40tude.net...
> When I check it directly by debugging, visually, ICON_BIG (on
> ALT-TAB Task Switcher) and ICON_SMALL2 (on application
> window; top-left) are the correct icon (ICON_SMALL is zero),
> but they're all auto generated by the system.
be?) up- or down-scaled a bit to fit your requirements. With no other data
I assume your "big" icons are near to 32x32 and your small ones near to
16x16. That would (logically) mean that the results would stay the same:
the 32x32 icon-resource for Alt-Tab and the 16x16 icon-resource for the app
itself. Both scaled to match the (a bit) different sizes.
In other words: even if your displays settings are abit different, the
sub-icon usage should still be the same.
So, your ICON_BIG should really return a different result from ICON_SMALL2.
But does it ?
> The latest MSDN on the web changed this to Windows 2000 and
> removed Windows 95.
> I'm guessing here also, that this changes is because they want to
> phase out old OS support
exists under XP and later versions, as mentioning DLL version numbers is
simply "not done" (fun when you try to get some info about some
"side-by-side" installations of (different versions of) "the same" DLL).
:-\
Regards,
Rudy Wieser
-- Origional message:
JJ <d...@nah.meh> schreef in berichtnieuws
Deanna Earley
May 28, 2013, 4:06:50 AM5/28/13
to
On 24/05/2013 23:40, JJ wrote:
> Interestingly, MSDN for VS2008 (October 2007) states that the minimum OS
> requirement for RegisterClassEx is Windows 95 or Windows NT 3.51. The latest
> MSDN on the web changed this to Windows 2000 and removed Windows 95.
>
> I'm guessing here also, that this changes is because they want to phase out
> old OS support.
They HAVE phased out support for the older versions, which is exactly
> Interestingly, MSDN for VS2008 (October 2007) states that the minimum OS
> requirement for RegisterClassEx is Windows 95 or Windows NT 3.51. The latest
> MSDN on the web changed this to Windows 2000 and removed Windows 95.
>
> I'm guessing here also, that this changes is because they want to phase out
> old OS support.
why it says "minimum supported version"
--
Deanna Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/
iCode Systems
(Replies direct to my email address will be ignored. Please reply to the
group.)
JJ
May 28, 2013, 6:41:45 AM5/28/13
to
On Tue, 28 May 2013 09:06:50 +0100, Deanna Earley wrote:
> They HAVE phased out support for the older versions, which is exactly
> why it says "minimum supported version"
Regardless, dropping support doesn't mean the RegisterClassEx function
> They HAVE phased out support for the older versions, which is exactly
> why it says "minimum supported version"
disappear from all of the unsupported OSes. It's still there.
Deanna Earley
May 28, 2013, 6:57:58 AM5/28/13
to
R.Wieser
May 28, 2013, 7:28:45 AM5/28/13
to
JJ,
> Regardless, dropping support doesn't mean the RegisterClassEx
> function disappear from all of the unsupported OSes. It's still there.
It is, and I have the same feelings about it. Removing absolute static
information for an OS version that you do not support anymore is an active
act, making the life of people (like me) who still activily use it a bit
(understatement) more difficult.
On the other hand, MS is a commercial organisation, not at all out to keep
customers that do not generate revenue anymore humoured. Its also quite
possible that removing that info is their way of "urging" the users of those
old versions of the OS to migrate to a more profitable, for them, version.
And to be honest, I cannot fault them for that.
Bottom line: Although I dislike them for it, I can also imagine a reason for
their doing so.
Regards,
Rudy Wieser
P.s.
If anyone knows where to find an MSDN for the discontinued versions I would
be obliged.
-- Origional message
JJ <d...@nah.meh> schreef in berichtnieuws
15p52ldveb1iw$.z5k8ftozv310$.dlg@40tude.net...
> Regardless, dropping support doesn't mean the RegisterClassEx
> function disappear from all of the unsupported OSes. It's still there.
information for an OS version that you do not support anymore is an active
act, making the life of people (like me) who still activily use it a bit
(understatement) more difficult.
On the other hand, MS is a commercial organisation, not at all out to keep
customers that do not generate revenue anymore humoured. Its also quite
possible that removing that info is their way of "urging" the users of those
old versions of the OS to migrate to a more profitable, for them, version.
And to be honest, I cannot fault them for that.
Bottom line: Although I dislike them for it, I can also imagine a reason for
their doing so.
Regards,
Rudy Wieser
P.s.
If anyone knows where to find an MSDN for the discontinued versions I would
be obliged.
-- Origional message
JJ <d...@nah.meh> schreef in berichtnieuws
JJ
May 28, 2013, 6:28:37 PM5/28/13
to
On Tue, 28 May 2013 11:57:58 +0100, Deanna Earley wrote:
> No, I was explaining why MSDN only listed 2000 and confirming your guesses.
Oh, OK. :)
> No, I was explaining why MSDN only listed 2000 and confirming your guesses.
JJ
May 28, 2013, 6:54:36 PM5/28/13
to
On Tue, 28 May 2013 13:28:45 +0200, R.Wieser wrote:
> If anyone knows where to find an MSDN for the discontinued versions I would
> be obliged.
I assume the older MSDN? Since using the latest one, there's no way to know
> If anyone knows where to find an MSDN for the discontinued versions I would
> be obliged.
if a function is already implemented in Windows 95. But it may be only good
for that purpose only.
You can get the MSDN Library for VS2008 SP1 here:
http://www.microsoft.com/en-us/download/details.aspx?id=20955
Though, I don't know what would happen to any newer Help System installation
if an older one is installed. You might want to test it under a VM.
R.Wieser
May 29, 2013, 5:25:36 AM5/29/13
to
Hey JJ,
> I assume the older MSDN? Since using the latest one, there's no way
> to know if a function is already implemented in Windows 95. But it may
> be only good for that purpose only.
"IsImplemented" is as easy as doing a TDUMP on the apropriate DLL :-)
Although ... I've found a few functions in w98se which only
"implementation" was to return an error or, even worse, an "yes, it worked"
status (like lstrcmpW). Not funny.
No, I mean a full MSDN describing the arguments for and quirks of the
function in those older OS versions. Like the MSDN we now have.
> You can get the MSDN Library for VS2008 SP1 here:
<snip>
> Though, I don't know what would happen to any newer Help System
installation
> if an older one is installed. You might want to test it under a VM.
Two reasons why I really dislike stuff like the above: It needs to have
that "Help System" software installed, and only that software can read the
information. Which only runs on a specific version of the OS.
Also, closed search-systems like that tend to make it hard to do a
free-style text-search ( (a windows port of) GREP works fine on the
text/html documents I've stored locally :-) ), or even to mark a specific
location (like I can make a shortcut to any document on my 'puter or the
Web). Most likely it also disallows me to annotate or change the contents.
:-\
No, I was referring to a possible existence of a website somewhere carrying
the older MSDN. Or maybe a zipped text/html download of it.
Thanks for the reference though.
Regards,
Rudy Wieser
-- Origional message
JJ <d...@nah.meh> schreef in berichtnieuws
d2vgv3evvz2r$.199wxxl2emhrf$.dlg@40tude.net...
> I assume the older MSDN? Since using the latest one, there's no way
> to know if a function is already implemented in Windows 95. But it may
> be only good for that purpose only.
Although ... I've found a few functions in w98se which only
"implementation" was to return an error or, even worse, an "yes, it worked"
status (like lstrcmpW). Not funny.
No, I mean a full MSDN describing the arguments for and quirks of the
function in those older OS versions. Like the MSDN we now have.
> You can get the MSDN Library for VS2008 SP1 here:
> Though, I don't know what would happen to any newer Help System
installation
> if an older one is installed. You might want to test it under a VM.
that "Help System" software installed, and only that software can read the
information. Which only runs on a specific version of the OS.
Also, closed search-systems like that tend to make it hard to do a
free-style text-search ( (a windows port of) GREP works fine on the
text/html documents I've stored locally :-) ), or even to mark a specific
location (like I can make a shortcut to any document on my 'puter or the
Web). Most likely it also disallows me to annotate or change the contents.
:-\
No, I was referring to a possible existence of a website somewhere carrying
the older MSDN. Or maybe a zipped text/html download of it.
Thanks for the reference though.
Regards,
Rudy Wieser
-- Origional message
JJ <d...@nah.meh> schreef in berichtnieuws
0 new messages