Smalltalk › Cincom › VisualWorks

Windows Registry

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Maarten Mostert

Windows Registry

Hi,

I don't manage to run James examples of the Registry package, and when trying to run the tests, they fail on Windows 7 (OS, 64 bit, image 32 bit).

Anyone knows how to solve this ?

Regards,

@+Maarten,

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Maarten Mostert

Re: Windows Registry

Hi Joachim,

I am running version 28 from the public store on vw 7.9.1 however running it on a french Vista 32 bit (Family Premium) still seems to give about identical test resuslts ?

Modifying read & write AccessMask does not seem to help, hower something is certainly wrong with the osKey which is nil !! as you can see in the enclosed stack. This was also the case on Win7 Pro (64bits).

Regards,

@+Maarten,

On Sunday, 3 March, 2013 08:23, "Joachim Geidel" <[hidden email]> said:

Hi Maarten,

> I don't manage to run James examples of the Registry package, and when trying to run

> the tests, they fail on Windows 7 (OS, 64 bit, image 32 bit).

> Anyone knows how to solve this ?

> Regards,

> @+Maarten,

Could you provide some more details? Which version of VisualWorks and of the Registry package have you been using, and which tests fail in which way?

I have been the last one to touch the package three years ago because I needed it for JNIPort, but as the only versions of Windows I have access to are 32bit versions of XP and Vista, I can't reproduce this right now. Just a guess: It could have to do with the structure of the Windows registry under the Microsoft Windows-32-on-Windows-64 (WOW64) subsystem. In theory, a Windows 32 bit application should be able to run without modifications under WOW64 (http://msdn.microsoft.com/en-us/library/aa384232.aspx), but I have not tested it.

I found a comment in the description of the RegOpenKeyEx function (http://msdn.microsoft.com/en-us/library/ms724897(v=vs.85).aspx) saying "The function fails with FILE_NOT_FOUND when you don't add KEY_WOW64_32KEY" in the samDesired parameter when running a 32 bit application (see also http://msdn.microsoft.com/en-us/library/ms724878%28VS.85%29.aspx). Without a 64 bit system, I can't tell if this has something to do with your problem. To test this, modify the following WindowsRegistry class methods:

readAccessMask

"^131097" "KEY_READ (0x20019)"

^ 16r20019 bitOr: 16r0200 "KEY_READ (0x20019) | KEY_WOW64_32KEY (0x0200)"

writeAccessMask

"^131078" "KEY_WRITE (0x20006)"

^16r20006 bitOr: 16r0200 "KEY_WRITE (0x20006) | KEY_WOW64_32KEY (0x0200)"

Does it change anything?

Best regards

Joachim

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Registry stack.zip (3K) Download Attachment

Registry failures.PNG (36K) Download Attachment

Joachim Geidel

Re: Windows Registry

Hi Maarten,

I have the same failures in 7.9.1 and 7.8.1, but not in 7.7.1. The problem disappears if you execute

WindowsRegistry.WindowsRegistryAPI recompileMethods

This seems to be a regression. In 7.7, a DLLCC problem had been fixed. The problem led to a wrong order in the compilation of type definitions when loading an ExternalInterface. This often resulted in types being compiled as simple pointer types (void *) instead of what they were actually declared to be. It seems that this is happening again in 7.8.1 and 7.9.1. The only VisualWorks versions where loading the WindowsRegistryAPI class works as it should are 7.7 and 7.7.1. For older versions, the postLoad block of the package fixes the type definitions.

HTH

Joachim

Von: <[hidden email]>
Datum: Dienstag, 5. März 2013 01:14
An: VWNC <[hidden email]>
Betreff: Re: [vwnc] Windows Registry

Hi Joachim,
I am running version 28 from the public store on vw 7.9.1 however running it on a french Vista 32 bit (Family Premium) still seems to give about identical test resuslts ?
Modifying read & write AccessMask does not seem to help, hower something is certainly wrong with the osKey which is nil !! as you can see in the enclosed stack. This was also the case on Win7 Pro (64bits).

Regards,

@+Maarten,

On Sunday, 3 March, 2013 08:23, "Joachim Geidel" <[hidden email]> said:

Hi Maarten,
> I don't manage to run James examples of the Registry package, and when trying to run
> the tests, they fail on Windows 7 (OS, 64 bit, image 32 bit).
> Anyone knows how to solve this ?
> Regards,
> @+Maarten,
Could you provide some more details? Which version of VisualWorks and of the Registry package have you been using, and which tests fail in which way?
I have been the last one to touch the package three years ago because I needed it for JNIPort, but as the only versions of Windows I have access to are 32bit versions of XP and Vista, I can't reproduce this right now. Just a guess: It could have to do with the structure of the Windows registry under the Microsoft Windows-32-on-Windows-64 (WOW64) subsystem. In theory, a Windows 32 bit application should be able to run without modifications under WOW64 (http://msdn.microsoft.com/en-us/library/aa384232.aspx), but I have not tested it.
I found a comment in the description of the RegOpenKeyEx function (http://msdn.microsoft.com/en-us/library/ms724897(v=vs.85).aspx) saying "The function fails with FILE_NOT_FOUND when you don't add KEY_WOW64_32KEY" in the samDesired parameter when running a 32 bit application (see also http://msdn.microsoft.com/en-us/library/ms724878%28VS.85%29.aspx). Without a 64 bit system, I can't tell if this has something to do with your problem. To test this, modify the following WindowsRegistry class methods:
readAccessMask
"^131097" "KEY_READ (0x20019)"
^ 16r20019 bitOr: 16r0200 "KEY_READ (0x20019) | KEY_WOW64_32KEY (0x0200)"
writeAccessMask
"^131078" "KEY_WRITE (0x20006)"
^16r20006 bitOr: 16r0200 "KEY_WRITE (0x20006) | KEY_WOW64_32KEY (0x0200)"
Does it change anything?
Best regards
Joachim
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Maarten Mostert

Re: Windows Registry

Thank you very much Joachim,

For the moment it just works !!

Does this mean that the DLLCC thing is a bug Andreas ?

Regards,

@+Maarten,

> "Joachim Geidel" <[hidden email]> |

Hi Maarten,

I have the same failures in 7.9.1 and 7.8.1, but not in 7.7.1. The problem disappears if you execute

WindowsRegistry.WindowsRegistryAPI recompileMethods

HTH

Joachim

Von: <[hidden email]>
Datum: Dienstag, 5. März 2013 01:14
An: VWNC <[hidden email]>
Betreff: Re: [vwnc] Windows Registry

Hi Joachim,

I am running version 28 from the public store on vw 7.9.1 however running it on a french Vista 32 bit (Family Premium) still seems to give about identical test resuslts ?

Modifying read & write AccessMask does not seem to help, hower something is certainly wrong with the osKey which is nil !! as you can see in the enclosed stack. This was also the case on Win7 Pro (64bits).

Regards,

@+Maarten,

On Sunday, 3 March, 2013 08:23, "Joachim Geidel" <[hidden email]> said:

Hi Maarten,

> I don't manage to run James examples of the Registry package, and when trying to run

> the tests, they fail on Windows 7 (OS, 64 bit, image 32 bit).

> Anyone knows how to solve this ?

> Regards,

> @+Maarten,

Could you provide some more details? Which version of VisualWorks and of the Registry package have you been using, and which tests fail in which way?

I have been the last one to touch the package three years ago because I needed it for JNIPort, but as the only versions of Windows I have access to are 32bit versions of XP and Vista, I can't reproduce this right now. Just a guess: It could have to do with the structure of the Windows registry under the Microsoft Windows-32-on-Windows-64 (WOW64) subsystem. In theory, a Windows 32 bit application should be able to run without modifications under WOW64 (http://msdn.microsoft.com/en-us/library/aa384232.aspx), but I have not tested it.

I found a comment in the description of the RegOpenKeyEx function (http://msdn.microsoft.com/en-us/library/ms724897(v=vs.85).aspx) saying "The function fails with FILE_NOT_FOUND when you don't add KEY_WOW64_32KEY" in the samDesired parameter when running a 32 bit application (see also http://msdn.microsoft.com/en-us/library/ms724878%28VS.85%29.aspx). Without a 64 bit system, I can't tell if this has something to do with your problem. To test this, modify the following WindowsRegistry class methods:

readAccessMask

"^131097" "KEY_READ (0x20019)"

^ 16r20019 bitOr: 16r0200 "KEY_READ (0x20019) | KEY_WOW64_32KEY (0x0200)"

writeAccessMask

"^131078" "KEY_WRITE (0x20006)"

^16r20006 bitOr: 16r0200 "KEY_WRITE (0x20006) | KEY_WOW64_32KEY (0x0200)"

Does it change anything?

Best regards

Joachim

_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Joachim Geidel

Re: Windows Registry

In 7.7, there were several fixed ARs which might be related to the
problem, but I don't remember any details:
57004 Allow redifined CType extensions to cause a recompile
57306 Inherited type definitions aren't loaded atomically if the
superclass defines only types, and no external methods
53348 Hierarchy implementors of CType>>hash are deficient

Regards,
Joachim

Von: <[hidden email]>
Datum: Samstag, 9. März 2013 08:04
An: Joachim Geidel <[hidden email]>
Cc: VWNC <[hidden email]>, Andres Valloud <[hidden email]>
Betreff: Re: [vwnc] Windows Registry

>Thank you very much Joachim,
>
>For the moment it just works !!
>Does this mean that the DLLCC thing is a bug Andreas ?
>
>Regards,
>
>@+Maarten,
>
>
>> "Joachim Geidel" <[hidden email]> |
>
>
>Hi Maarten,
>I have the same failures in 7.9.1 and 7.8.1, but not in 7.7.1. The
>problem disappears if you execute
> WindowsRegistry.WindowsRegistryAPI recompileMethods
>This seems to be a regression. In 7.7, a DLLCC problem had been fixed.
>The problem led to a wrong order in the compilation of type definitions
>when loading an ExternalInterface. This often resulted in types being
>compiled as simple pointer types (void *) instead of what they were
>actually declared to be. It seems that this is happening again in 7.8.1
>and 7.9.1. The only VisualWorks versions where loading the
>WindowsRegistryAPI class works as it should are 7.7 and 7.7.1. For older
>versions, the postLoad block of the package fixes the type definitions.
>HTH
>Joachim

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc