Batch file utility to close CD drive
Cliff
Does anything that exist anywhere? Thanks in advance.
--
Cliff
DONALD G. DAVIS
>I'm looking for a utility that will close the cd drive from a batch file.
>Does anything that exist anywhere? Thanks in advance.
I answered this same request in alt.freeware, but will respond
here too in case others are interested. (This has been discussed in
alt.msdos.batch before.)
I wrote a tiny DOS program that will open/close CD-ROM trays by
drive letter, from the command line or batch file. It's fully functional
under MS-DOS and Win9x, but only the "open" function works under NT/2000/
XP. It's not on Internet sites, but I'll e-mail copies on request. A Web
search will locate several other similar programs.
--Donald Davis
Cliff
I'd be very interested if you find the time to implement the close function
under XP. That seems to be the one that's most needed.
--
Cliff
Si Ballenger
The below vbs file opens and closes the CD drive door. With the
CD door already open, you can run the below and the drawer will
close. Run the batch file you already have to open the door, then
have another batch file run the below vbs file to close the door.
====CD.vbs===========
Set oWMP = CreateObject("WMPlayer.OCX.7" )
Set colCDROMs = oWMP.cdromCollection
if colCDROMs.Count >= 1 then
For i = 0 to colCDROMs.Count - 1
colCDROMs.Item(i).Eject
Next ' cdrom
For i = 0 to colCDROMs.Count - 1
colCDROMs.Item(i).Eject
Next ' cdrom
End If
Barry Skidmore
> I'd be very interested if you find the time to implement the close
> function under XP. That seems to be the one that's most needed.
>
I was slammed very hard for posting an XP-related question on this
newsgroup. You take your life in your hands by doing so, based on my sad
experience.
DONALD G. DAVIS
I would like to do that if someone could tell me exactly why the
"close" function doesn't work under the NT line of Windows. My program
works by Interrupt 2Fh calls to MSCDEX or other equivalent drivers; i.e.,
the Win98 MSCDEX equivalent. It appears that the NT emulation of MSCDEX
is imperfect, so that the "close" call that works in DOS or Win9x doesn't
under NT. I have no idea how to overcome this. I've seen equivalent
32-bit Windows programs that do close the tray under NT, but don't know
how they do it, or if they work in a way that I could emulate in my MS-DOS
16-bit .ASM code.
--Donald Davis
DONALD G. DAVIS
>====CD.vbs===========
>End If
I tried this on my system (Win98SE) and it aborts with an error
"ActiveX component can't create object: 'WMPlayer.OCX.7'" for line 1.
I've never used Windows Scripting Host; is there an installation or
initialization I need to go through to make it work?
--Donald Davis
Joe Batch
DONALD G. DAVIS wrote:
> >> I wrote a tiny DOS program that will open/close CD-ROM trays by
> >> drive letter, from the command line or batch file. It's fully
> >> functional under MS-DOS and Win9x, but only the "open" function works
> >> under NT/2000/ XP. It's not on Internet sites, but I'll e-mail copies
> >> on request. A Web search will locate several other similar programs.
Here is a (similar?) program (2 actually). I have only one
CD-ROM drive so I don't know how this will work with multiple
drives.
:: cd-opcl.bat
@echo off
if "%1"=="1" goto close
if "%1"=="0" goto open
echo. Syntax: %0 0³1
echo. opens or closes cd-rom tray
echo. 0 (zero) to open, 1 (one) to close
goto end
:open cdtray
echo:`h}aXP5y`P]4nP_XW(F4(F6(F=(FF)FH(FL(Fe(FR0FTs*}`A?+,>%temp%.\cd-open.com
echo:fkOU):G*@Crv,*t$HU[rlf~#IubfRfXf(V#fj}fX4{PY$@fPfZsZ$:K68$.>>%temp%.\cd-open.com
echo:.T]6KRw'RmSf/*VtTZ$K+}n\I/~{R'K*X{/wW$Q3;[5:Jl.oh_fRW'[g9'e>>%temp%.\cd-open.com
echo:0sum5FrT_0rLen$'?qN$$$$$$$$$$$$$$$F7{{/t$fJb$$/)e#>>%temp%.\cd-open.com
for %%c in (call del) do %%c %temp%.\cd-open.com
goto end
:close cdtray
echo:`h}aXP5y`P]4nP_XW(F4(F6(F=(FF)FH(FL(Fe(FR0FTs*}`A?+,>%temp%.\cd-close.com
echo:fkOU):G*@Crv,*t$HU[rlf~#IubfRfXf(V#fj}fX4{PY$@fPfZsZ$:K68$.>>%temp%.\cd-close.com
echo:.T]6KRw'RmSf/*VtTZ$K+}n\I/~{R'K*X{/wW$Q3;[5:Jl.oh_fRW'[g9'e>>%temp%.\cd-close.com
echo:0sum5FrT_0rLen$'?qN$$$$$$$$$$$$$$$F8SC4t$fJb$$/)e#>>%temp%.\cd-close.com
for %%c in (call del) do %%c %temp%.\cd-close.com
:end
--
Batfiles: The DOS batch file programming handbook & tutorial
http://purl.oclc.org/net/Batfiles/
Using MS-Dos7 Commands http://purl.oclc.org/net/Msdos7/
DONALD G. DAVIS
>>>The below vbs file opens and closes the CD drive door. With the
>>>CD door already open, you can run the below and the drawer will
>>>close. Run the batch file you already have to open the door, then
>>>have another batch file run the below vbs file to close the door.
>>
>>>====CD.vbs===========
>>
>>>Set oWMP = CreateObject("WMPlayer.OCX.7" )
>>>Set colCDROMs = oWMP.cdromCollection
>>>if colCDROMs.Count >= 1 then
>>
>>>For i = 0 to colCDROMs.Count - 1
>>>colCDROMs.Item(i).Eject
>>>Next ' cdrom
>>
>>>For i = 0 to colCDROMs.Count - 1
>>>colCDROMs.Item(i).Eject
>>>Next ' cdrom
>>
>>>End If
>>
>> I tried this on my system (Win98SE) and it aborts with an error
>>"ActiveX component can't create object: 'WMPlayer.OCX.7'" for line 1.
>>I've never used Windows Scripting Host; is there an installation or
>>initialization I need to go through to make it work?
>>
>> --Donald Davis
>I don't think the script host is included in win95, and not sure
>about 98. The 5.5 version can be downloaded from MS for use with
>win95. The 5.6 version is for 2K/XP. You probably find info at
>the below link and a google search.
>http://msdn.microsoft.com/scripting
Yes, Windows Scripting Host is built into Win98SE; WSH is what
gives the ActiveX error when I run your script (by "start cd.vbs" at a
command prompt, or in the "Run" line).
--Donald Davis
DONALD G. DAVIS
>DONALD G. DAVIS wrote:
>> >> I wrote a tiny DOS program that will open/close CD-ROM trays by
>> >> drive letter, from the command line or batch file. It's fully
>> >> functional under MS-DOS and Win9x, but only the "open" function works
>> >> under NT/2000/ XP. It's not on Internet sites, but I'll e-mail copies
>> >> on request. A Web search will locate several other similar programs.
>Here is a (similar?) program (2 actually). I have only one
>CD-ROM drive so I don't know how this will work with multiple
>drives.
I have CD-ROM drives R and S. The code in your batch file works
only on the first drive, R. For multiple drives, the programs need a way
for the command line to specify which one is to be addressed.
The CD-OPEN.COM and CD-CLOSE.COM files generated by this batch
work on my system, but when I run them under CodeView to see how they
differ from my own code, CodeView shows instructions that seem to be
nonsense. Are these your own programs? I would be interested to see the
.ASM files corresponding to these .COMs if you could post them or send
them to me.
--Donald Davis
Joe Batch
DONALD G. DAVIS wrote:
>
> I have CD-ROM drives R and S. The code in your batch file works
> only on the first drive, R. For multiple drives, the programs need a way
> for the command line to specify which one is to be addressed.
>
> The CD-OPEN.COM and CD-CLOSE.COM files generated by this batch
> work on my system, but when I run them under CodeView to see how they
> differ from my own code, CodeView shows instructions that seem to be
> nonsense. Are these your own programs? I would be interested to see the
> .ASM files corresponding to these .COMs if you could post them or send
> them to me.
You might also look at the code I posted in the "Question about ANSI"
thread.
http://www.google.com/groups?selm=FU54%2B%24aeB%40news.cis.dfn.de
If take _only_ the ASCII assembler code from each file and compare
with fc/b, you get:
0000008E: 5C 5B
This corresponds exactly to the one significant byte in
the code that is different in the two files.
\ and [ (or respectively, 5C and 5B in hex).
ASCII Extended Scan
Key Dec Hex Char Dec Hex Char Dec Hex
-----------------------------------------------------------
\ 92 5C \ 86 56
[ 91 5B [ 9 09
cd-open and cd-close codes compare like this.
000000D3: 37 38
000000D4: 7B 53
000000D5: 7B 43
000000D6: 2F 34
I'll e-mail you the debug equivalent code.
DONALD G. DAVIS
I think I see what must be going on. The apparent nonsense
instructions are esoteric code that is required for a .COM program whose
opcodes are restricted to 7-bit ASCII characters. During most if its
execution, it seems to be building the actual working code, which ends up
overwriting part of the original. Clever, if convoluted. The 7-bit ASCII
.COM file is 228 bytes. The more straighforward DEBUG code is 75 bytes
and is easily followed in CodeView.
--Donald Davis
Todd Vargo
"DONALD G. DAVIS" <dgd...@nyx.net> wrote in message
news:10587423...@irys.nyx.net...
FWIW, on my Win98SE system, which has the 5.6 version update installed, it
opens both of my CD trays but closes neither.
--
Todd Vargo (body of message must contain my name to reply by email)
Joe Batch
DONALD G. DAVIS wrote:
> >DONALD G. DAVIS wrote:
> >>
> >> I have CD-ROM drives R and S. The code in your batch file works
> >> only on the first drive, R. For multiple drives, the programs need a way
> >> for the command line to specify which one is to be addressed.
Thanks for the feedback on that.
> I think I see what must be going on. The apparent nonsense
> instructions are esoteric code that is required for a .COM program whose
> opcodes are restricted to 7-bit ASCII characters. During most if its
> execution, it seems to be building the actual working code, which ends up
> overwriting part of the original. Clever, if convoluted.
Undoubtedly the code may be seen as being convoluted from a debug
assembler point of view, but straightforward from an ASCII assembler
point of view. The fact that the ASCII code uses more bytes is
not important, IMO. For example, take two different human languages,
one you know and one that you don't. It is like comparing text that
says the same thing in both languages. The text in the known language
may be shorter than the corresponding text in the unknown language,
but that [in itself] does not mean the text in the unknown language
in convoluted.
> The 7-bit ASCII
> .COM file is 228 bytes. The more straighforward DEBUG code is 75 bytes
> and is easily followed in CodeView.
I have experienced on many systems that debug is not present,
because the system administrators do not allow it. ASCII
assembler could be handy in cases like these. It is probably
safe to say that ASCII assembler will work, across the board,
on more systems than debug assembler.
Todd Vargo
"Joe Batch" <joe_d...@yahoo.com> wrote
> I have experienced on many systems that debug is not present,
> because the system administrators do not allow it. ASCII
> assembler could be handy in cases like these. It is probably
> safe to say that ASCII assembler will work, across the board,
> on more systems than debug assembler.
In this day and age, where AV-ware is prominent on business systems,
anything that creates an executable is suspect. Don't be surprised if
creating a .com program on the fly sets off an AV alarm or two.
Joe Batch
"Todd Vargo" wrote:
> In this day and age, where AV-ware is prominent on business systems,
> anything that creates an executable is suspect. Don't be surprised if
> creating a .com program on the fly sets off an AV alarm or two.
I won't be surprised. However, it may be possible to create
executibles on some systems that disallow downloading them.