Llamada a Advapi32.lib

[Josber]

Hola @fastpho, ya no me da ese error, el "linkado" lo hace sin problemas, pero al ejecutar la prueba que has puesto no me hace nada, es más da un error "Exception Number : UNDEFINED_EXCEPTION(C000041D)"

No sé si puede ser porque, si transformo el valor X"80000001" que has puesto a una variable s9(9), falta un dígito para que quepa, (X"80000001" = *2.147.483.649‬, 10 dígitos), y quizás debería ser una variable S9(10), porque yo, en el ejemplo que me envió en su día Rapinto, no usaba ese valor para HKCU, si no X"01000080". Aunque ésta vez, sí he estado mirando en muchas más páginas por internet y el valor que pones tú es el correcto.

(Ya sé que tú en el ejemplo has puesto X"80000002" que es HKLM, pero yo necesito que sea X"80000001", que es HKCU)

Gracias y perdona las molestias.
Un salu2.-

[fastpho]

Hola @Josber

@Rapinto lo definio asi porque era un "capo"

entonces se hara como rapinto dice

01  HKCU                              PIC X(04)    VALUE X"01000080".
01  HKEY-CURRENT-USER         REDEFINES HKCU PIC S9(10) COMP-5. 

lo debe redefinir pq el valor es mayor 999999999
haciendo un display a HKEY-CURRENT-USER nos da 2.147.483.649
pasale este valor como VALUE

   CALL "RegCreateKeyExA" WITH stdcall LINKAGE    
         USING  BY VALUE         HKEY-CURRENT-USER
                BY REFERENCE     subkey
                BY VALUE         Reserved 
                BY VALUE         NULO                              
                BY VALUE         REG_OPTION_NON_VOLATILE
                BY VALUE         KEY_ALL_ACCESS
                BY VALUE         lpSecurityAttributes
                BY REFERENCE     hregkey
                BY REFERENCE     neworused
         RETURNING retval

Probalo a ver como sale
Saludos...

[fastpho]

@Josber, Este ejemplo esta probado y funciona bien , el post #12 explotaba

 WORKING-STORAGE SECTION.
 01  HKCU                                PIC X(04)    VALUE X"01000080".
 01  HKEY-CURRENT-USER    REDEFINES HKCU PIC 9(9)   COMP-5. 
 01  Reserved                            PIC 9(9)   COMP-5 VALUE 0.    *> Reserved
 01  NULO                                PIC 9(9)   COMP-5 VALUE 0.    *> NULO
 01  REG_OPTION_NON_VOLATILE             PIC 9(9)   COMP-5 VALUE 0.    *> dwOptions
 01  KEY_ALL_ACCESS                      PIC 9(9)   COMP-5 VALUE 983103.  *> samDesired    HEX F003F
 01  lpSecurityAttributes                PIC 9(9)   COMP-5 VALUE 0.    *> lpSecurityAttributes
 01  hregkey                             PIC 9(9)   COMP-5 VALUE 0.    *> phkResult
 01  neworused                           PIC 9(9)   COMP-5 VALUE 0.    *> lpdwDisposition recibe 1 La clave no existía y fue creada , recive 2 si existía y simplemente se                       abrió sin cambiarla    
   
 01 subkey                               PIC X(80) value "Software\PruebaSOFT" & X"00".                      *> lpSubKey  
 
 01 retval                               PIC S9(9)   COMP-5.               *> retorno de la func

 PROCEDURE       DIVISION.
     CALL "RegCreateKeyExA" WITH stdcall LINKAGE    
         USING  BY VALUE         HKEY-CURRENT-USER
                BY REFERENCE     subkey
                BY VALUE         Reserved 
                BY VALUE         NULO                              
                BY VALUE         REG_OPTION_NON_VOLATILE
                BY VALUE         KEY_ALL_ACCESS
                BY VALUE         lpSecurityAttributes
                BY REFERENCE     hregkey
                BY REFERENCE     neworused
         RETURNING retval.
     DISPLAY "Resultado de la funcion: " , RETVAL.
     DISPLAY "Resultado neworused:     " , neworused. 

Saludos ...

[Kuk]

A ver chavalería, los COMP-5 son binarios nativos, es decir que los PIC de Cobol no tiene efecto directo, sólo son indican cuantos bytes tiene el campo dividiendo el PIC por 2. O sea que un PIC S9(9) COMP-5 es un Integer nativo y puede almacenar valores de 10 posiciones: Un PIC S9(9) COMP-5 puede almacenar desde -2,147,483,648 hasta 2,147,483,647 y un PIC 9(9) COMP-5 (sin signo) desde 0 hasta 4,294,967,295


También no hace falta invertir los valores de HKLM y HKCU, simplemente hay que definirlos directamente en binario nativo:

    01  HKLM                              PIC 9(9) COMP-5    VALUE H"80000002".
    01  HKCU                              PIC 9(9) COMP-5    VALUE H"80000001".

Si la máquina es Little-Endian, ya hará la inversión automáticamente. Así este código funcionaría sobre una máquina Big-Endian sin tener que modificarlo.

Si definimos los valores en alfanumérico con un REDEFINES, no habrá inversión y así limitamos el código a máquinas Little-Endian sólo.

[Kuk]

@fastpho, el post Nº12 explota porque el PIC S9(10) COMP-5 es tomado por un Big Integer de 8 bytes, es lo mismo como si hubieras definido PIC S9(18)

[Josber]

A ver chavalería, los COMP-5 son binarios nativos, es decir que los PIC de Cobol no tiene efecto directo, sólo son indican cuantos bytes tiene el campo dividiendo el PIC por 2. O sea que un PIC S9(9) COMP-5 es un Integer nativo y puede almacenar valores de 10 posiciones: Un PIC S9(9) COMP-5 puede almacenar desde -2,147,483,648 hasta 2,147,483,647 y un PIC 9(9) COMP-5 (sin signo) desde 0 hasta 4,294,967,295


También no hace falta invertir los valores de HKLM y HKCU, simplemente hay que definirlos directamente en binario nativo:

    01  HKLM                              PIC 9(9) COMP-5    VALUE H"80000002".
    01  HKCU                              PIC 9(9) COMP-5    VALUE H"80000001".

Si la máquina es Little-Endian, ya hará la inversión automáticamente. Así este código funcionaría sobre una máquina Big-Endian sin tener que modificarlo.

Si definimos los valores en alfanumérico con un REDEFINES, no habrá inversión y así limitamos el código a máquinas Little-Endian sólo.

A ver @Kuk, definiéndolo como tú has puesto, o en éste caso, como he hecho yo que por un casual es igual al tuyo,

        01 HKCU                         PIC  9(9)   COMP-5 VALUE H"80000001".   *> HKEY_CURRENT_USER

sigue teniendo el mismo problema, (te lo digo porque acabo de probarlo), ocupa 10 posiciones y el máximo son 9, (ya sé que puede almacenar un valor superior pero, si bajo el número a 9 posiciones, decimal 999.999.999, hexadecimal *3B9AC9FF‬, no da problemas al compilar, no sé si será tema de alguna directiva que haya que ponerle al precompilador o algo por el estilo), por lo que al compilar, da el error

JMN2034I-S The numeric literal of the VALUE clause specifies a value which is truncated to zero. Figurative constant ZERO is assumed.

La única manera es como ha puesto @fastpho, que es como lo hacía yo antes, y, es como si fuera una transformación de Little_endian a Big_endian, pero quitándole una posición ¿?¿?¿?, que es lo que no entiendo.

Lo de limitar el código a máquinas Little_endian, la mayoría son con procesadores Intel, y no habrá problemas, porque es el sistema suyo de facto, no sé ahora, qué procesadores usan Big_endian, pero, te aseguro que no es mi caso.

Un salu2 y mil gracias.-

[Kuk]

@Josber, se nota que llevo años sin tocar Fujitsu, estoy con Micro Focus y ahí sí que es como lo decía. Es decir que un COMP-5 acepta valores superiores a 9 posiciones, cosa que me parece normal ya que se trata de un binario nativo. Físicamente los valores de 10 posiciones entran, si no de hecho lo del REDEFINES no funcionaría. Lo que pasa es que hay que "engañarlo" asignando el valor byte por byte en un campo alfanumérico.

Una burrada la verdad, y eso que me encanta el compilador de Fujitsu.

He hecho tests, porque está ahí el tipo BINARY-LONG, que me he dicho lo mismo hay que usar este, que equivale a PIC S9(9) COMP-5. Pero dice que es signado, y si le pongo UNSIGNED como dice el manual, el compilador insulta con un error y no compila

Vamos, que es un fallito de los de Fujitsu, pero bueno, mientras que haya solución.

Os he mareado para nada chavales, lo siento

[fastpho]

Hola @Josber, @Kuk,

La explicacion de la solucion no estaria en las posiciones ..... si 9 o 10 etc
esta en que la representacion de las variables en cuestion que son de 4 bytes (80 00 00 01) = HKEY-CURRENT-USER
y de ahi que funciona perfectamente el REDEFINES declarando como PIC 9(9) COMP-5 para representar los 4 bytes necesarios PIC X(4).

1 a 4 digitos son 2 bytes     = PIC 9(4)  COMP-5
5 a 9 digitos son 4 bytes     = PIC 9(9)  COMP-5 ---> Public Const HKEY_CURRENT_USER = &H80000001
10 a 18 digitos son 8 bytes   = PIC 9(18) COMP-5

Segun el manual de fujitsu cobol 5.0 pagina 369-370

The size of the storage area allocated to a binary item is
determined as follows by the number of digits specified by a
PICTURE clause.
1 to 4 digits: 2 bytes
5 to 9 digits: 4 bytes
10 to 18 digits: 8 bytes

Esta declaracion tipo BINARY-SHORT BINARY-LONG BINARY-DOUBLE en power-cobol 5.0 no existe
me parece que las pusieron en fujitsu cobol 9.00 como para moderninzarlo pero sigue siendo

BINARY-SHORT  ---- PIC 9(4) COMP-5.
BINARY-LONG   ---- PIC 9(9) COMP-5.
BINARY-DOUBLE ---- PIC 9(18) COMP-5

Saludos ...

[Josber]

@fastpho, no da error al compilar como tú dices, pero por ejemplo

        01 HKCUSER                  PIC XXXX VALUE X"80000001".
        01 HKCU     REDEFINES HKCUS     PIC  9(9) COMP-5.

al no coger bien por no aceptar más de 9 posiciones, en éste caso HKCU, en vez de tener el valor 2.147.483.649, que es el que le corresponde en el REDEFINES, se trunca al valor 016.777.344, (según el QUICK-WATCH del debuger), y no funciona correctamente el programa, a pesar de que, por lo que he podido comprobar, ese es el valor que tengo yo que usar para que me funcione, es lo que vengo diciendo,

        01  HKEY_CU                     PIC  X(4)  VALUE X"01000080".   *> HKEY_CURRENT_USER
        01  HKCU    REDEFINES HKEY_CU   PIC  9(9)   COMP-5.

es de la única manera que he conseguido que funcione sin problemas, porque de éstas dos maneras, no funciona, con signo y sin signo, es igual

        01  HKCU                     PIC  9(9)  COMP-5 VALUE 016777344.
 
                               ó
 
        01  HKCU                     PIC  9(9)  COMP-5 VALUE X"01000080".

Al final, he conseguido lo que quería, pero, me tiene "enmarranao" el tema y, por internet no hay mucha info al respecto.

Un salu2.-

[Kuk]

@Josber, te estás liando por lo de Endianess. No te olvides de que al usar COMP-5 que es un binario dependiente de la máquina, binario nativo, es el sistema el que se encarga de almacenarlo en memoria como corresponda que para Little-Endian el valor h"80000001" se almacena como h"01000080" por lo de Endianess.
Pero cuando hacemos REDEFINES no se hace almacenamiento sino un mapeo directo sobre algo que ya está almacenado en memoria. Así que si le pones el valor x"80000001" en un campo alfanumérico y lo redefines en COMP-5, el sistema no lo vuelve a almacenar según el orden correspondiente a Little-Endian (que para Little-Endian en memoria debe estar como x"01000080"). Así que el valor que te dará es el inverso por byte.

Resumiendo, el valor en decimal de esto:

            01 HKCUSER                  PIC XXXX VALUE X"80000001".
            01 HKCU     REDEFINES HKCUS     PIC  9(9) COMP-5.

Es 16.777.344 porque en memoria va almacenado en este orden 80 00 00 01 pero como la máquina es Little-Endian empezará por el último byte que contiene 01 y lo leera como 01 00 00 80 que da el valor 16.777.344 en vez de 2.147.483.649 que tú necesitas.

No sé si me explico.

Total, ejecuta este código, ya verás:

 ENVIRONMENT     DIVISION.
 DATA            DIVISION.
 WORKING-STORAGE SECTION.
 01 HKCUSER                        PIC XXXX VALUE X"80000001".
 01 HKCU     REDEFINES HKCUSER     PIC  9(9) COMP-5.   
 PROCEDURE       DIVISION.
 
     display "HKCU: " HKCU