siglo21

Hola mis estimados lectores, hoy les platicaré el asunto ese de usar Linux y Windows.

Durante mucho tiempo hemos podido usar Windows y Linux en un solo equipo, gracias a los sistemas multiboot podemos instalar una distribución de Linux y un Windows (o más en algunos casos), A lo mejor, en un disco duro particionado o en discos duros por separado. Y gracias al sistema GRUB poder elegir con que sistema operativo queremos trabajar al iniciar nuestro ordenador. En algunos otros casos, podemos instalar un sistema operativo base (Windows o Linux) y posteriormente instalar un sistema virtualizador e instalar uno o más sistemas operativos "virtualizados" en nuestro sistema Huesped. Por obvias razones, es mejor instalar los sistemas operativos en su propia partición o disco duro ya que el sistema operativo instalado funciona mejor en su propio Sistema de Archivos. Los instaladores de Windows y Linux nos dan la facilidad de particionar a nuestro gusto los discos duros durante la instalación para instalar el sistema operativo de nuestros deseos. Los instaladores de Windows son muy básicos, ya que solamente nos permiten agregar y eliminar particiones para poder hacer espacio para nuestra instalación de Windows, y prácticamente, secuestra el proceso de inicialización del sistema para que solamente nuestra instalación de Windows sea la única que se pueda inicializar (o cualquier otra instalación de Windows que ya tengamos instalada, siempre y cuando estén en otro disco duro) y esto es debido a las particiones adicionales que crea Windows, además de manejar (Sin informar por supuesto) sus propio FS (cosa que abandonaron después de Windows XP que nos dejaba seleccionar entre NTFS o FAT). Linux, al contrario, nos ofrece una herramienta de particionado muy poderoso (GParted) que nos permite INCLUSO redimensionar las particiones existentes sin eliminar información, para hacer "espacio" para el sistema operativo que vamos a instalar. 

No todos los usuarios tienen las ganas necesarias para lidiar todos estos temas de instalar sistemas operativos, particionar discos duros y lidiar con las configuraciones para poder ejecutar su sistemas multiboot con sus multisistemas (asuntos que escribiré en otra ocasión), así que se inclinan al uso de la virtualización, primeramente de manos de VMWare y actualmente de VMWare (muy robusto actualmente) y VirtualBox (De Oracle y, aunque no es un producto libre, se ofrece sin costo para los usuarios finales). Windows tenia su fork para trabajar con sistemas virtualizados, el mítico Virtual PC que terminó junto con Windows 7 (Tema del que no ahondaré en esta ocasión ya que ese no es la ocasión).

Asi que con multiboot o virtualización podemos trabajar con dos Sistemas Operativos independientemente de nuestras necesidades y dado el nivel de desarrollo de nuestros sistemas operativos podemos realizar prácticamente las mismas actividades en sistemas operativos, para el usuario final práctimanente las diferencias son tan infimas que uno no se percata en que trabaja uno, si Windows o Linux. pero ¿Si tengo un proyecto propio elaborado en ambiente Linux Y NO quiero portarlo a Windows para no tener que lidiar con cambiar de sistema o virtualizar el otro sistema? Windows 10 nos da la respuesta para este reto: el Linux Subsystem (o WSL). Gracias a esta nueva característica de Windows, podemos correr una distribución de Linux de manera concurrente dentro de Windows (Con los beneficios evidentes de intercambio de archivos entre ambos sistemas y el uso de servicios que se ejecuten en ambos sistemas ya que los servicios (como posiblemente un MySql o un Servidor Apache ejecutándose en Windows) son facilmente accesibles desde Linux ejecutándose en el mismo equipo y sin tener que lidiar con direcciones IP virtualizadas)

Así que para iniciar nuestro proceso, inicemos configurando Windows para poder acceder a esta interesante característica de Windows, dado que la característica no viene activada por "defecto" en nuestro windows (Ya que no a todos les interesa "nalguear" linux desde Windows) hay que activarla... Así que abrimos nuestra interfaz de configuración, nos desplazamos a la opción de "Aplicaciones" y del lado derecho (Ahí abajo de donde dice "Aplicaciones y Características") hacer click en la opción de "Características Opcionales". Nos vamos hasta ABAJO donde dice "Más características de Windows" que abrirá otra ventana titulada "Características de Windows" con algunas opciones seleccionables dentro de un cuadro. Buscamos la opción Subsistema de Windows para Linux y la resaltamos y ya que estamos ahí activamos también Hyper V, Dado que esta opción tiene sub opciones, seleccionamos el símbolo + para seleccionar todas estas opciones (Si están en GRIS puede que las opciones internas estén restringidas por no estar soportadas por nuestro equipo), la opción Hyper V no es necesaria si planeamos usar el sistema WSL pero si, si planeamos usar WSL2 (que trae mejoras significativas, pero que requiere que nuestro equipo soporte la virtualización por Hardware). Hacemos Click en Aceptar y después del proceso de activación de WSL Windows nos pedirá que reiniciemos el equipo. 

Una vez regresando del reinicio obligado, procederemos a instalar una distribución de Linux, así que procedemos a hacer uso de la tienda de Windows. Abra la tienda de aplicaciones de Windows, en el cuadro de busqueda colocar "Linux" y le damos a la Lupa para que nos busque las aplicaciones, en los primeros resultados encontraremos algunas distribuciones (Las más populares), Ubuntu (en varios sabores), SUSE, Kali, Oracle, Debian, Etc. Seleccionamos nuestra distribución favorita y procedemos a la instalación haciendo CLICK en Instalar.

 Cambiar de Windows a Windows es una gran aventura, sobre todo por que cuando cambiamos de versión de Windows a uno "Mejor", muchas de las cosas que ya funcionaban bien antes, ya no funcionan tan bien o de plano, dejan de funcionar.

Eso pasa cuando trabajas con Visual Basic 6.0. Cuando pasas de Windows XP a Windows Vista o 7 resulta que tu programa para hacer programas ya no funciona o es un PEDO hacerlo funcionar. Y es que para proseguir con la evolución esperada se tendría también que pensar en una plataforma de desarrollo y eso fue lo que pasó con el producto. Para empezar Visual Basic fue integrado a una plataforma integral de desarrollo, es decir, el producto fue integrado a una plataforma llamada Visual Studio formado por un entorno de desarrollo integrado por el propio Visual Basic, Visual C++ y Visual FoxPro (Y algunas otras herramientas de desarrollo de aplicaciones). Hasta ahí vamos bien por que podemos seguir trabajando con nuestras aplicaciones desarrolladas para Visual Basic y poder ingresar al fabuloso entorno de desarrollo de C++ y la posibilidad de portar nuestras aplicaciones de Foxpro al entorno gráfico de Windows. 

Pero después nos pasaron de nuestro Visual Studio 6.0 a Visual Studio 2002 donde nos cambiaron de golpe el enfoque a Visual Basic que es nuestra arma de batalla. Al integrarla a la plataforma NET, cambia de tajo todo... mientras los nuestros códigos fueron evolucionando junto con las versiones de Visual Basic con pequeños cambios, migrar de Visual Basic 6.0 a Visual Basic 2002 o Visual Basic.NET. Portar una aplicación que teníamos codificada en Visual Basic 6 a Visual Basic NET pasó a ser una labor titánica ya que aunque el nuevo entorno de trabajo nos facilitaba un proceso de migración, este no siempre podía lidiar bien con las diferencias en codificación que, nos dejaba a veces en tantos aprietos que terminábamos por recodificar nuestras aplicaciones desde cero. 

Y es que la codificación de Visual Basic 6 a Visual Basic.NET varia bastante, además de que las propiedades y los procedimientos de los componentes varian también bastante. El manejo de los procedimientos como funciones se vuelve un pequeño quebradero de cabeza (Y digo, pequeño, por que después de agarrarle el 20 es relativamente sencillo). El problema que veo en el cambio de VB a NET es la conversión de nuestros códigos ya que a veces no son muy pequeños y a veces tenemos que revisar miles de lineas de código lo que hace que la tarea se vuelva engorrosa y tediosa lo que nos hace considerar mejor la reescritura de un código ya existente, por lo que el uso de una máquina virtual se vuelve prácticamente impresindible si es que queremos seguir trabajando con nuestras aplicaciones desarrolladas con un Visual Basic 6.0 (o menor) dado que, nuestro Visual Basic ya no es compatible con las nuevas versiones de Windows.

Instalar Visual Basic 6 o Visual Studio 6 en Windows 7 es toda una aventura (Y supongo que es aún más instalarlo en Windows 10+). 

Según alguna información que he consultado en el internet, el proceso para instalar VB 6 en Windows 7 (aún no probado en el Windows 10) se realiza de la siguiente forma:

Se copia el contenido del CD a una carpeta del disco duro, posteriormente se copia el contenido de una carpeta llamada SETUP a la parte superior del directorio, posteriormente se renombra un archivo llamado vb98ent.stf o en algunos casos el archivo vs98pro.stf por acmsetup.stf, y se procede a ejecutar el programa llamado ACMSETUP.EXE con privilegios elevados de administrador. Aunque realicé este proceso en un Windows 7 y funcionó correctamente, aunque con algunas advertencias pero no en otro Windows 7. La instalación que no funcionó marca un error indicando que debo de ejecutar el programa SETUP para proceder a la instalación la cual se ejecutó correctamente sin advertencias. En ambas instalaciones, me indicaba un error que cancelaba la instalación, se resolvió desactivando en las opciones de instalación la instalación del explorador de objetos OLE (en la opción TOOLS). 

Después de terminar la instalación, se deben de cambiar algunas opciones del ejecutable de visual basic. En la ubicación C:\Program Files (x86)\Microsoft Visual Studio\VB98 se encuentra un archivo ejecutable llamado VB6, hay que abrir las propiedades de la aplicación (Boton derecho - Propiedades - Compatibilidad) y activar el modo de compatibilidad con Windows XP y marcar las opciones de "Deshabilitar efectos visuales, Deshabilitar composición de escritorio, Deshabilitar el ajuste de escala de la pantalla si se usa la configuración elevada de ppp y por último marcar que se ejecute con nivel de administrador.

Solamente existen algunas pequeñas cosas que hay que corregir, ya que al parecer, algunos componentes no se registran correctamente (Los que se encuentran ubicados en la carpeta de \Windows\SysWow64\). de esto nos enteramos en el momento en que intentamos usar componentes extras que no se encuentran en la plantilla estandar y que se activan en las opciones Project - Components. Al momento de activar algún componente, nos indicará un mensaje de error indicandonos que dicho componente no está registrado. Para hacer eso, debemos usar una ventana de CMD (en modo administrador) y registrar el componente correspondiente usando el comando regsvr32 componente.OCX. Si el problema persiste es que hay que hacer un paso extra. Algunas de los componentes que no suelen funcionar a pesar de registrar los OCX, son los componentes extras que se instalan junto con VB, me refiero a los common-controls 6.0 (Microsoft Windows Common Controls 6.0) que son 3 componentes adicionales. Para hacerlos funcionar se usa la instrucción regtlib, pero el problema es que este no se encuentra disponible en la versión de Windows 7 por lo que la alternativa es usar regtlibv12.exe, en mi caso lo encontré en esta carpeta:   C:\Windows\Microsoft.NET\Framework\v4.0.30319 si en tu caso, no lo encuentras, puedes buscarlo en la unidad donde tengas instalado Windows, yo lo hice con un simple DIR regt*.exe /s. Para facilitar el proceso (Y en caso de requerirlo más adelante) procedí a copiar el archivo a la carpeta de Windows\SysWow64\ y ejecutar desde ahí la instrucción regtlibv12 msdatsrc.tlb con lo que después de intentar activar los componentes que me causaban problemas, esos se activaron y usaron sin producir más errores.