| |
|
Desde que pulsamos el boton de encendido de nuestro PC hasta... (parte 16) |
|
|
|
| |
Por Jose Manuel Tella Llop, extraído de microsoft.public.es.windows98
DESDE QUE PULSAMOS EL BOTON DE NUESTRO PC HASTA..... (Parte 16)
---------------------------------------------------- PARAMETROS DE CONFIGURACION - AUTOEXEC.BAT
------------------------------------------ * Como introducción (y casi, casi como unico resumen), podemos decir que el autoexec.bat se encarga, o puede encargarse de ejecutar cualquier programa MsDOS, así como de establecer las condiciones de "entorno" (ya las veremos mas adelante), de todo el MsDOS, y lo que es mas importante: de todo Windows. Esto ultimo, deriva de que Windows "hereda" todo el entorno que tenía al arrancar. * Extrictamente este archivo no es necesario (al igual que el config.sys), pero por desgracia, el MsDOS y el Windows, estan pensados para configuraciones regionales USA (así como el teclado). Por tanto como nuestro sistema (y nuestro teclado) no está en USA, debemos incorporar unas pocas lineas, tanto en el config, como en el autoexec. Recordemos que en el config eran: device=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=034,850,C:\WINDOWS\COMMAND\country.sys Y en el autoexec.bat, son: mode con codepage prepare=((850) C:\WINDOWS\COMMAND\ega.cpi)
mode con codepage select=850
keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys (en ambas me estoy refiriendo a "España" y teclado Español. Para configuraciones en Latino America, estas lineas variarán ligeramente) Basicamente, en estas lineas, estoy configurando la tabla de codigos, como la 850, el país España como 034, y el teclado como español "sp". ** NOTA: Es importante, sobre todo si vamos a tener más de un sistema operativo, es decir, si nuestro sistema va a convivir con NT 4 o con Windows 2000, que estas lineas esten correctamente definidas. El problema nos puede venir causado, porque si no tenemos correcta la pagina de codigos en Windows 98, los caracteres acentuados y caracteres locales (como la "ñ") aunque la veamos correctamente en pantalla, se almacenan con la tabla de codigos por defecto del MsDOS. Entonces veríamos correctamente los nombre de archivos acentuados, pero internamente el nombre estaría almacenado con otro codigo. En esta situacion, si instalamos Windows NT o Windows 2000, estos, al configurarse (recordad que son independientes y no se apoyan en el MsDOS), se configuran con la tabla correcta de codigos: 850. Por tanto los caracteres acentuados en nombres de archivos, serán otros. De esta manera, un scandisk desde Windows 98 a la particion NT, nos dará errores en los nombres de archivo, y lo que es mas grave: intentará arreglarlos (estropeando el correcto desde "su" sistema). Exactamente igual nos pasará desde Windows 2000. CONDICIONES DE ENTORNO
---------------------- * Se entiende por entorno, auqellas variables que son comunes a todo el sistema. Se heredan entre los procesos. * En general no son necesarias, excepto para programas particulares que las vayan a utilizar. Las variables que queramos que se vean en "todo" el sistema y que puedan ser leidas por un programa, se asignan en el autoexec mediante el comando SET. Esto lo utilizan muchas aplicaciones. La variable más curiosa de entorno, es la TEMP. Esta la utilizan desde el comienzo del MsDOS, muchas aplicaciones, y en particular, tambien la utiliza Windows. Por defecto, sino está definida, el propio MsDOS le asigna el contenido C:\WINDOWS\TEMP y por costumbre desde los inicios del DOS, esta carpeta se utiliza para escribir en ella ficheros temporales que necesiten las aplicaciones, y que por definicion pueden ser borrados en cualquier momento. Los programas o aplicaciones bien realizadas, deberían además ser las responsables de borrarlos. Pero esto, quizá sea mucho pedir... Tal y como estabamos comentando con el entorno, nosotros podemos definir en el autoexec otra localizacion de la carpeta TEMP. Lo mas normal es tener: SET TEMP=C:\TEMP y a su vez tener creada la carpeta TEMP en C:. ** Una de las variables de entorno mas importante en el PATH (camino). Cuando tecleamos un programa para su ejecucion, tanto el MsDOS como Windows, buscan el programa en la carpeta en donde estamos en ese momento, y si no lo encuentran, lo buscan en el "camino" que esté definido en nuestra variable PATH. Por defecto, sino especificamos un path, en Windows por defecto el path es C:\WINDOWS;C:\WINDOWS\COMMAND (se debe tomar nota, que los distintos caminos, se separan por punto y coma). Como PATH, ademas, es una variable de entorno, puede ser asignada mediante el comando SET. Es lo mas comodo. Imaginar que queremos "añadir" al PATH que tuviesemos en un momento determinado, la carpeta C:\KK. Bien, lo mas sencillo sería escribir: SET PATH=%PATH%;C:\KK Fijaros que lo que estamos haciendo, es decirle que el nuevo PATH, es igual al anterior (en este caso, se pone %PATH% -es decir encerrado entre simbolos %), y a continuacion, separado por punto y coma, el camino que queremos añadir. NOTA 1: Para ver el PATH que tenemos en un determinado momento, podemos abrir una ventana MsDOS y teclear simplemente PATH. Esto nos mostrará el contenido del PATH. Iguelmente en una ventana MsDOS, si tecleamos el comanto SET nos mostrará todas las variables de entorno, y en particular el propio PATH, ya que esta es una variable de entorno. NOTA 2: Cuando dentro de Windows,vamos a Inicio->Ejecutar y tecleamos el nombre de un programa, Windows primero buscará en C:\WINDOWS\SYSTEM y si no lo encuentra, a continuacion buscará en el PATH. EMPIEZA LA OPTIMIZACION DE NUESTRO SISTEMA
------------------------------------------ Recordar que el directorio de archivos temporales, "debe" estar vacio. Si tiene muchos archivos, degrada de una manera apreciable las prestaciones y velocidad de Windows. Es conveniente borrarlo de vez en cuando. Y ahora la pregunta del millón: ¿no podriamos utilizar el propio autoexec.bat, para que cada vez que arranquemos, sea él el encargado de "limpiar" esta carpeta?. Pues sí podemos y "debemos" hacerlo. Una manera muy sencilla de hacerlo, es incorporar las siguiente lienas de codigo en nuestro autoexec. if not exist c:\temp\*.* goto cont0
attrib c:\temp\*.* -s -h -r
echo S | del c:\temp\*.* >nul
:cont0 Esto nos borrará el contenido de la carpeta C:\TEMP. Si tuviesemos los temporales en otra carpeta (por ejemplo, en la carpeta por defecto de Windows C:\WINDOWS\TEMP), deberemos sustituir C:\TEMP por el nombre de la carpeta que tuviesemos los temporales en nuestro sistema. Es importante recordar además que debe sustituirse la "S" de la linea "echo S", por una "Y" (sin las comillas) si tuviesemos Windows en Inglés. CONFUSION EXISTENTE EN TORNO AL MSCDEX
-------------------------------------- En muchas consultas realizadas y debido a cierta confusion que existe con el MSCDEX y la posibilidad de ver o nó nuestra CDROM desde MsDOS puro, voy a hablar un poco sobre este tema. Notas a tener encuenta: 1) No le hace falta a Windows,que tengamos definido "nada" en nuestro config y autoexec, para ser capaz de ver la CDROM. 2) Si tuviesemos algo definido, es mas que probable que a Windows no le quede mas remedio que acceder a nuestra CDROM, utilizando el viejo metodo de acceso de 16 bites, perdiendo entonces la capacidad de acceso en 32 bites. Ademas, tambien es mas que probable, que si nuestra CDROM fuese IDE, perdamos el acceso a 32 bites tambien en nuestro disco duro si este está en el mismo cana IDE. * Con lo anterior, quiere decir: "cuidadito" con lo que tenemos o ponemos allí. ** Repasemos un poco el antiguo MsDOS, para entender como se accedía a una CDROM (sistema de 16 bites). Para acceder a la CDROM, necesitamos dos componentes software: 1) Un driver de dispositivo (por ser driver, debe estar en el config.sys), que nos permite ver un dispositivo de tipo "stream" (o de flujo) como un dispositivo "record" (orientado a registro). Recordad que un CDROM es un dispositivo "stream" -como si fuese una unidad de cinta-. 2) Un programa (por tanto, montado en el autoexec), que sea capaz de acceder al dispositivo virtual montado en el punto 1), y devolvernos los datos como si fuese una unidad de "disco". Este programa es un estandard de Microsoft: el MSCDEX (pero podría ser cualquier otro y de echo existieron algunos durante la vida del antiguo MsDOS). * A partir de ahora me voy a referir unicamente a los CDROM IDE. (la idea basica, de todas maneras, es igualmente extrapolable a los CDROM SCSI). ** Hasta que surgió Windows 98, y nos incorporó un driver casi "universal" para todas las unidades de CDROM, era bastante normal en el MsDOS em deter drivers del tipo: DEVICE=C:\HITACHI.SYS /D:MSCD001 .... o
DEVICE=C:\PIOONER.SYS /D:...... Es decir un driver de nuestro fabricante de CDROM (normalmente lo identificamos por el parametro /D:MSCD001) en el config.sys para poder ver nuestra CDROM. Igualmente teniamos una linea del tipo MSCDEX /D:MSCD001 en el autoexec. Fijaros que el nombre puesto en /D:MSCD001, puede ser cualquiera, con tal que sean el mismo en el driver del config y en el programa MSCDEX. Bien, retomando el tema, estabamos diciendo que Windows nos aporta un driver "casi" universal: el OAKCDROM.SYS (que podemos encontrarlo en el disco de inicio de Windows 98, o bien en la carpeta C:\WINDOWS\COMMAND\EBD). Por tanto incorporando este driver en el config y a su vez invocando al programa MSCDEX, tendríamos acceso a la CDROM en modo MsDOS puro. ** Pero... debido a los problemas que he comentado al principio de este capitulo, esto está completamente desaconsejado. Perderiamos muchas prestaciones en nuestro sistema. ** Entonces, la pregunta es ¿como puedo acceder a la CDROM, al reiniciar en modo MsDOS, desde windows?. Bueno, y ademas, existe un problema: un driver de dispositivo, "debe" cargarse en el config.sys. Veamos tres posibilidades para solucionar este problema: 1) Cargar el OAKCDROM.SYS en el config de nuestro propio Windows. Y *no* cargar el MSCDEX. Con esto evitamos que el acceso se haga a 16 bites. Posteriormente crearnos un archivo en nuestro directorio de Windows,llamado DOSSTART.BAT que unicamente tuviese la linea de MSCDEX /D:MSCD001. Si este el archivo ya existiese, incorporarle dicha linea. Esta solucion funciona, pero no me gusta por dos motivos: uno, consumo de memoria MsDOS (al cargar el driver anterior), que luego no sirve para nada bajo Windows. Y segundo motivo, este tipo de drivers en combinacion con ciertas controladoras y unidades de CDROM, pueden causar inestabilidades al Windows. 2) Utilizar algun programa de los llamados "cargadores" de drivers. Por ejemplo, Creative Labs, tenia en su servidor FTP, un programa llamado CTLOAD, que era capaz de cargar un driver una vez que estuviesemos en MsDOS y sin necesidad de incorporarlo en el config. La manera de cargarlo sería entonces: CTLOAD C:\WINDOWS\COMMAND\EBD\OAKCDROM.SYS /D:MSCD001
MSCDEX /D:MSCD001 (y suponiendo que el programa CTLOAD, lo hemos dejado por ejemplo en C:\windows\command para que lo encuentre en el path). Incorporando estas lineas en el DOSSTART.BAT citado anteriormente, tendriamos acceso a la CDROM al reinicar en modo MsDOS. 3) Tercera posibilidad: utilizar un config y autoexec propio y crear un acceso directo a un "command.com" desde el escritorio con ese config y autoexec propio que incorporte esas lineas cada una en su correspondiente archivo. Tampoco me gusta, porque esto implica el tener que "mantener" otros config y autoexec. La solucion mas "limpia" en mi opinion es la 2). SE INICIA YA LA CARGA DE WINDOWS
-------------------------------- **** Bueno, y este será el siguiente capitulo......
Volver a
Artículos y FAQs
| 
