Odpowiadamy Czytelnikom

Otrzymaliśmy interesujący list, który zmuszeni byliśmy jednak skrócić ze względu na brak miejsca. Przytaczamy zasadnicze zarzuty i propozycje z tego listu.

Otrzymaliśmy interesujący list, który zmuszeni byliśmy jednak skrócić ze względu na brak miejsca. Przytaczamy zasadnicze zarzuty i propozycje z tego listu.

W artykule p. M. Łakomego (ComputerWorld 33/63) przeczytałem o tym jak należy sprawdzać, czy pracuje się w DOS-owskim okienku Windows.

A. Nie ma potrzeby wykonywać tak skomplikowanych czynności jak:

a) wychodzenia z Dos-u (EXIT);

b) sprawdzanie zmiennych środowiskowych;

c) szukania w pamięci (mem/c | more)

(wygodniej będzie: mem/c | find "WIN"/I).

W Windows 3.1 wystarczy nacisnąć Alt+Tab. Jeśli nic się nie wydarzy - to jesteśmy w DOS-ie.

B. Jeśli koniecznie chce się szukać zmiennej: "windir=C:/WINDOWS" to wystarczy użyć takiej komendy:

SET | FIND "windir="

Jeśli chodzi o programy typu BAT oto cytat z artykułu:

"Niestety nie możemy napisać takiego pliku wsadowego, który jest w stanie testować obecność zmiennej "windir", gdyż DOS zmienia na duże litery każdy testowany parametr pliku wsadowego, a tymczasem zmienna ta zapisana jest małymi literami."

Nieprawda! DOS zamienia na duże litery tylko nazwy zmiennych środowiskowych.

Proponuję zrobić dwa programy typu BAT.

1. windir.bat (tak właśnie ma się nazywać!)

2. wintest.bat

TREŚĆ WINDIR.BAT

@echo Uwaga! Pracujesz w okienku WINDOWS

@echo %0 = %1

(drugi wiersz pokazuje jedynie treść zmiennej "windir")

TREŚĆ WINTEST.BAT

@echo off

set | find "windir=" > WIN#TEST.BAT

echo echo Nie wykryłem WINDOWS >> WIN#TEST.BAT

CALL WIN#TEST

del WIN#TEST.BAT

Teraz wystarczy wpisać WINTEST i nacisnąć ENTER.

Jak to działa?

1. SET | FIND "windir="

Powyższa komenda powinna zwrócić tekst w rodzaju: windir=C:\WINDOWS jeśli istnieje zmienna "windir", albo nie zwróci NIC, jeśli nie istnieje. Natomiast SET | FIND "windir=" > WIN#TEST.BAT spowoduje utworzenie zbioru WIN#TEST.BAT i wpisanie do niego wyniku działania tej komendy.

2. Następny wiersz dopisuje do zbioru WIN#TEST.BAT komunikat o tym, że nie pracujemy w Windows.

3. Czasowy plik WIN#TEST.BAT będzie wyglądał następująco:

windir=C:\WINDOWS

echo Nie wykryłem WINDOWS

o ile zmienna "windir" istniała. Jeśli nie istniała, to nie będzie zawierał pierwszego wiersza.

4. Co zrobi DOS po komendzie CALL WIN#TEST.BAT? Jeśli trafi na: windir=C:\WINDOWS, to spróbuje wykonać program WINDIR z parametrem C:\Windows i w ten sposób uruchomi WINDIR.BAT i już z niego nie wróci do WIN#TEST.BAT tylko do WINTEST.BAT, czyli nie wypisze komunikatu.

C. Dalej czytałem o tym jak zabezpieczyć się przed wywołaniem programu, którego nie należy wywoływać. NIE! NIE! i jeszcze raz NIE!

Proponowana metoda zupełnie nie przypadła mi do gustu. Dlaczego, jeśli przez nieuwagę uruchomiłem program, którego nie powinienem, mam zaraz wracać do... no właśnie do czego? Jeśli wywołałem DOS z Windows, to do Windows, ale jeśli z jakiegoś innego powodu wywołam drugą, czy kolejną kopię SHELL-a, to wrócę o jeden poziom wyżej.

Proponuję do WINDIR.BAT dopisać jeszcze jedną linię:

@pause

i w swoich BAT-ach wpisać zamiast EXIT

call WINTEST

Jeśli będę pracował w Windows - to zobaczę coś takiego:

Uwaga! Pracujesz w okienku WINDOWS

windir=C:\WINDOWS

press any key to continue...

Albo, jeśli jest się zwolennikiem radykalnych rozwiązań zamiast

@pause wpisać @exit lub też:

@echo Wracamy do Windows

@pause > NUL

@exit

Tomasz Padzik, 02-784 Warszawa ul. Sosnowskiego 4 m. 2

Odpowiedź:

Ad A. Istotnie w Windows 3.1 istnieje prosta metoda przechodzenia między otwartymi aplikacjami Windows, polegająca na naciśnięciu klawiszy Alt-Tab. Zachodzi tylko pytanie, kto pracując w DOS-ie naciska Alt-Tab przed uruchomieniem na przykład programu Speedisk, dość skutecznie niszczącego zawartość dysku stałego, jeśli zostanie wywołany z okienka DOS-owego w Windows i bardzo przydatnego przy porządkowaniu dysku w DOS-ie.

Ad B. Wcale nie zachęcam Czytelników do szukania zmiennej "windir". Informuję ich jedynie, że Windows także w DOS-ie naznacza swą obecność i pokazuję, gdzie to można sprawdzić.

Co do niemożności napisania pliku wsadowego, sprawdzającego czy jesteśmy w "czystym" DOS-ie czy w okienku DOS-owym w Windows, to istotnie prawda. Proszę zwrócić uwagę, że Panu udało się to dopiero za pomocą trzech plików wsadowych i programu FIND.

Przyznaję się do błędu, że DOS jedynie nazwy zmiennych środowiskowych zamienia na duże litery, nie zaś parametry pliku wsadowego.

Ad C. No cóż... Jeśli koniecznie chce Pan sobie zniszczyć zawartość dysku stałego, wolna wola! Jeśli nawet jesteśmy w kolejnej warstwie shella, to wywołanie pliku wsadowego:

EXIT

FBX

spowoduje powrót do wyższej warstwy shella, ale nie wywoła programu FBX. I o to właśnie chodzi! Zwracam także uwagę, że ostatecznie doszedł Pan do wstawienia EXIT w pliku wsadowym do wywoływania niebezpiecznych programów!

Pozostawiam do uznania Czytelników, co jest prostsze w użyciu: Pańskie rozwiązanie, czy moja propozycja.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200