Ver la Versión Completa : [Sintaxis] Llamada a Advapi32.lib
Josber
17 de octubre de 2022, 19:24
A ver, he utilizado muchas veces la llamada a ésta API usando RegOpenKeyExA RegSetValueExA y RegCloseKey, aunque antes, siempre creaba a mano los valores necesarios en el registro de Windows para que no me diese ningún error, por lo que no tenía ningún problema, ahora quiero que si esas claves, no existen. crearlas, el problema es que cuando voy a usar RegCreateKeyEx, (me da igual usar esa que el Alias "RegCreateKeyExA", pasa lo mismo), al compilar, el "Linker" me tira el error
error LNK2001: unresolved external symbol _RegCreateKeyExA@20
Sé que esa función pertenece a esa librería, tengo el .lib incluido en el proyecto y también tengo incluido el parámetro ALPHAL(WORD), ¿alguna pista de qué puede pasar o faltar?, porque ya digo, con las otras llamadas a esa librería, no tengo ningún problema.
Muchas gracias
fastpho
17 de octubre de 2022, 19:59
Hola @Josber, prueba con la libreria de este link Labs/advapi32.lib at master · Aekras1a/Labs · GitHub (https://github.com/Aekras1a/Labs/blob/master/Labs/WinDDK/7600.16385.1/lib/win7/i386/advapi32.lib) , por que me pasaba algo parecido con la libreria winspool me daba el mismo error que a vos al compilar y @Kuk me paso un link donde hay varias librerias y funciono bien
Saludos...
Josber
17 de octubre de 2022, 20:19
Gracias @fastpho, he descargado esa librería y, aunque es un poco más grande que la mía (60k), sigue dando el mismo error
fastpho
17 de octubre de 2022, 20:26
@Josber, Podrias poner unas lineas de codigo para ver como llamas a la libreria
Saludos...
Josber
17 de octubre de 2022, 20:35
Sí claro @fastpho, sin problemas
*
01 hkcu PIC xxxx VALUE x"01000080".
01 currentuser redefines hkcu PIC s9(9) COMP-5.
01 keyall PIC xxxx VALUE x"3F000000".
01 allaccess REDEFINES keyall PIC s9(9) COMP-5.
01 keywrite pic xxxx value x"00020006".
01 kwrite REDEFINES keywrite PIC s9(9) comp-5.
01 reg-sz PIC s9(9) COMP-5.
01 handle PIC s9(9) COMP-5 VALUE 0. *> receives handle to the registry key
01 len PIC s9(9) COMP-5 VALUE 0.
01 res PIC s9(9) COMP-5 VALUE 0. *> Resultado de la operación
01 SEC_ATTRIB PIC S9(9) COMP-5 VALUE 0. *> Descriptor de seguridad por defecto (0)
01 NEW_OR_USED PIC S9(9) COMP-5. *> receives flag for if the key was created or opened
01 POW-ARG-KEY PIC X(8192) VALUE SPACES.
01 POW-ARG-NAME PIC X(8192) VALUE SPACES.
01 POW-ARG-VALUE PIC X(8192).
CALL "RegCreateKeyExA" WITH stdcall LINKAGE
USING BY VALUE handle
BY VALUE SEC_ATTRIB
BY REFERENCE POW-ARG-KEY
BY VALUE NEW_OR_USED
BY REFERENCE POW-ARG-NAME
RETURNING res
END-CALL.
Si falta algo, me lo dices
Mil gracias
fastpho
17 de octubre de 2022, 20:36
@Josber, Podrias poner unas lineas de codigo para ver como llamas a la libreria
Saludos...
Ejemplo de codigo en visual basic : vb6-winapi/registry.bas at master · mmcguill/vb6-winapi · GitHub (https://github.com/mmcguill/vb6-winapi/blob/master/registry.bas)
Kuk
17 de octubre de 2022, 20:42
@Josber, compañero le estás pasando 5 parámetros, pero es que esta función espera 8 y no 5: RegCreateKeyExA function (winreg.h) - Win32 apps | Microsoft Learn (https://learn.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regcreatekeyexa)
De ahí lo de _RegCreateKeyExA@20. Son 4 bytes por parámetro, sea cual sea la propiedad (VALUE, REFERENCE etc.). 4 x 5 = 20
Lo que espera son 8 así que 8 x 4 = 32, si el error fuera _RegCreateKeyExA@32 entonces sí que podríamos pensar que hay algún problema con la librería. Pero mientras que la llamada no lleve cantidad correcta de parámetros, podría ser que tu librería fuera válida también.
fastpho
17 de octubre de 2022, 22:14
@Josber, lo compile y no da error , no lo quise correr para no tocar mi registro
Ejemplo
01 HKEY_LOCAL_MACHINE PIC XXXX VALUE X"80000002". *> hKey
01 H_L_M redefines HKEY_LOCAL_MACHINE PIC S9(9) COMP-5.
01 subkey PIC X(8196). *> lpSubKey
01 Reserved PIC S9(9) COMP-5 VALUE ZERO. *> Reserved
01 NULO PIC X. *> lpClass
01 REG_OPTION_NON_VOLATILE PIC S9(9) COMP-5 VALUE ZERO. *> dwOptions
01 KEY_ALL_ACCESS PIC S9(9) COMP-5 VALUE 983103. *> samDesired HEX F003F
01 lpSecurityAttributes PIC S9(9) COMP-5 VALUE ZERO. *> lpSecurityAttributes
01 hregkey PIC S9(9) COMP-5. *> phkResult
01 neworused PIC S9(9) COMP-5. *> lpdwDisposition recibe 1 La clave no existía y fue creada , recive 2 si existía y simplemente se abrió sin cambiarla
01 retval PIC S9(9) COMP-5. *> retorno de la func
MOVE "SoftwarePruebaSOFT" TO subkey.
MOVE SPACES TO NULO
CALL "RegCreateKeyExA" WITH stdcall LINKAGE
USING BY REFERENCE HKEY_LOCAL_MACHINE
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
END-CALL.
DISPLAY "Resultado: " , RETVAL.
DISPLAY "neworused" , neworused.
Saludos ...
Josber
18 de octubre de 2022, 08:44
Muchas gracias @fastpho, voy a probarlo y te digo algo.
Estuve mirando el primer ejemplo que "pillé" en Vb, y en ese ejemplo. sólo le pasaba esos parámetros, no se me ocurrió mirar más ejemplos, si es que algunas veces, tengo errores de novato, pero, lo dicho, compruebo y digo algo
Un salu2.-
Kuk
18 de octubre de 2022, 15:05
Muchas gracias @fastpho, voy a probarlo y te digo algo.
Estuve mirando el primer ejemplo que "pillé" en Vb, y en ese ejemplo. sólo le pasaba esos parámetros, no se me ocurrió mirar más ejemplos, si es que algunas veces, tengo errores de novato, pero, lo dicho, compruebo y digo algo
Un salu2.-
Seguramente fuera un ejemplo para Windows 95 o algo así :D
Siempre verifica en la página de MS. Normalmente el Nº de parámetros no suele cambiar, pero hay casos que sí ;)
Josber
18 de octubre de 2022, 20:02
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
18 de octubre de 2022, 21:17
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
19 de octubre de 2022, 00:39
@Josber, Este ejemplo esta probado y funciona bien :yupi: , el post #12 (https://www.cobolforo.es/usertag.php?do=list&action=hash&hash=12) explotaba:tonto:
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 "SoftwarePruebaSOFT" & 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
19 de octubre de 2022, 09:38
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
19 de octubre de 2022, 09:46
@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
19 de octubre de 2022, 20:25
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
20 de octubre de 2022, 09:24
@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 :D
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
20 de octubre de 2022, 19:52
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
20 de octubre de 2022, 20:39
@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
21 de octubre de 2022, 09:25
@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
Kuk
21 de octubre de 2022, 11:58
A ver chavales, a mi este código me funciona en PowerCOBOL v10.1 :yess:
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 HKCU-BL BINARY-LONG VALUE h"80000001". *> Binario Nativo, Integer
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 HKCU-BL
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
Y para marearos más aún, este también :lamet: :D
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 INT IS TYPEDEF BINARY-LONG.
01 HKCU TYPE INT VALUE h"80000001".
01 Reserved TYPE INT VALUE 0. *> Reserved
01 NULO TYPE INT VALUE 0. *> NULO
01 REG_OPTION_NON_VOLATILE TYPE INT VALUE 0. *> dwOptions
01 KEY_ALL_ACCESS TYPE INT VALUE 983103. *> samDesired HEX F003F
01 lpSecurityAttributes TYPE INT VALUE 0. *> lpSecurityAttributes
01 hregkey TYPE INT VALUE 0. *> phkResult
01 neworused TYPE INT 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 TYPE INT. *> retorno de la func
PROCEDURE DIVISION.
CALL "RegCreateKeyExA" WITH stdcall LINKAGE
USING BY VALUE HKCU
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
Josber
21 de octubre de 2022, 15:48
A ver chavales, a mi este código me funciona en PowerCOBOL v10.1 :yess:
A mí no me funciona ese código, será por ser PWC9 y tener un pequeño fallo tocawebs el compilador, no sé si a otros les funcionará
Un salu2.-
Josber
21 de octubre de 2022, 20:38
Vale @Kuk, ahora comprendo lo de big y little_endian, en ambos casos, les "da la vuelta", pensaba que sólo lo hacía en el caso de big_endian y que con el otro, lo almacenaba tal y como estaba, de todas maneras, sigo sin verle la utilidad al tema de darles la vuelta a los valores, supongo que alguna tendrá, por supuesto.
Un saludo y mil gracias.-
Kuk
24 de octubre de 2022, 09:40
@Josber, es al revés :D en Big-Endian es tal cual, en Little-Endian se le da la vuelta. ;)
Las razones... pues aquí se citan por lo que veo: architecture - What is the advantage of little endian format? - Software Engineering Stack Exchange (https://softwareengineering.stackexchange.com/questions/95556/what-is-the-advantage-of-little-endian-format)
Josber
24 de octubre de 2022, 09:58
@Josber, es al revés :D en Big-Endian es tal cual, en Little-Endian se le da la vuelta. ;)
Las razones... pues aquí se citan por lo que veo: architecture - What is the advantage of little endian format? - Software Engineering Stack Exchange (https://softwareengineering.stackexchange.com/questions/95556/what-is-the-advantage-of-little-endian-format)
Es verdad, lo he puesto al revés pero, con tanto ver, mirar, probar ... al final, te haces la picha un lío :loco: :loco:, y sí, ahora que lo he leído, le veo más utilidad, no había pensado yo en ese tema, pero es correctísimo y muy lógico.
Un salu2.-
vBulletin v3.8.7, Derechos ©2000-2026, Jelsoft Enterprises Ltd.