Dos Batch File

[Edward]

Well.. It's a very advanced question.. It will exercise your minds, and solve
my problem.. I thank very much who can help me.. (and forgive me for my poor
english)

That's the question:

I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY AUTOEXEC.BAT OR NOT.

In another words: If autoexec is in execution or is finished.

I tried this way:

Inside the program I tried to modify or delete autoexec.bat. So, if I could,
autoexec is close and if I couldn't, it's open and then I'd have my answer...

It didn't work, because even when it's running you can delete it, and at the
time to run the next command inside it, a message like "batch file is
missing" appears.

So, I believe somewhere in memory the name of the batch file running is
storaged.

Where is it?

Does anybody have a different way to solve my problem?

Thank you very much..

Ed

 

[Buffalo]

"Edward" <Edward@discussions.microsoft.com> wrote in message
news:F7B763EF-93F2-4670-8B2B-E5CB5617569F@microsoft.com...
> Well.. It's a very advanced question.. It will exercise your minds, and
solve
> my problem.. I thank very much who can help me.. (and forgive me for my
poor
> english)
>
> That's the question:
>
> I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY AUTOEXEC.BAT OR
NOT.
>
> In another words: If autoexec is in execution or is finished.
>
> I tried this way:
>
> Inside the program I tried to modify or delete autoexec.bat. So, if I
could,
> autoexec is close and if I couldn't, it's open and then I'd have my
answer...
>
> It didn't work, because even when it's running you can delete it, and at
the
> time to run the next command inside it, a message like "batch file is
> missing" appears.
>
> So, I believe somewhere in memory the name of the batch file running is
> storaged.
>
> Where is it?
>
> Does anybody have a different way to solve my problem?
>
> Thank you very much..
>
> Ed
Perhaps you could just rename autoexec.bat to autoexec.bak or
similar.
At the C:\ prompt, type ren autoexec.bat autoexec.bak and press
Enter.
Reboot if you need to see if the 'storaged' program does or doesn't come
up.
If this causes problems, simply just rename autoexec.bak to autoexec.bat and
press Enter. .

 

[Franc Zabkar]

On Mon, 26 Nov 2007 04:34:00 -0800, Edward
<Edward@discussions.microsoft.com> put finger to keyboard and
composed:

>Well.. It's a very advanced question.. It will exercise your minds, and solve
>my problem.. I thank very much who can help me.. (and forgive me for my poor
>english)
>
>That's the question:
>
>I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY AUTOEXEC.BAT OR NOT.
>
>In another words: If autoexec is in execution or is finished.
>
>I tried this way:
>
>Inside the program I tried to modify or delete autoexec.bat. So, if I could,
>autoexec is close and if I couldn't, it's open and then I'd have my answer...
>
>It didn't work, because even when it's running you can delete it, and at the
>time to run the next command inside it, a message like "batch file is
>missing" appears.
>
>So, I believe somewhere in memory the name of the batch file running is
>storaged.
>
>Where is it?
>
>Does anybody have a different way to solve my problem?
>
>Thank you very much..
>
>Ed

I don't know how to detect autoexec.bat directly, but you could test
for a flag in an environment variable.

For example, add these lines to autoexec.bat and then test for the
existence of the environment variable, flag, within your program.

set flag=%0
your_dos_program
set flag=

%0 contains the name of the calling batch routine, in this case
autoexec.bat.

For much better answers I suggest you repost your question to
alt.msdos.batch.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Franc Zabkar]

On Tue, 27 Nov 2007 06:16:34 +1100, Franc Zabkar
<fzabkar@iinternode.on.net> put finger to keyboard and composed:

>I don't know how to detect autoexec.bat directly, but you could test
>for a flag in an environment variable.
>
>For example, add these lines to autoexec.bat and then test for the
>existence of the environment variable, flag, within your program.
>
> set flag=%0
> your_dos_program
> set flag=
>
>%0 contains the name of the calling batch routine, in this case
>autoexec.bat.

Another way is to call your program as follows:

your_dos_program %0

Then parse the command line arguments within your program.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Franc Zabkar]

On Tue, 27 Nov 2007 06:23:11 +1100, Franc Zabkar
<fzabkar@iinternode.on.net> put finger to keyboard and composed:

>On Tue, 27 Nov 2007 06:16:34 +1100, Franc Zabkar
><fzabkar@iinternode.on.net> put finger to keyboard and composed:
>
>>I don't know how to detect autoexec.bat directly, but you could test
>>for a flag in an environment variable.
>>
>>For example, add these lines to autoexec.bat and then test for the
>>existence of the environment variable, flag, within your program.
>>
>> set flag=%0
>> your_dos_program
>> set flag=
>>
>>%0 contains the name of the calling batch routine, in this case
>>autoexec.bat.
>
>Another way is to call your program as follows:
>
> your_dos_program %0
>
>Then parse the command line arguments within your program.

Here's a third way. It relegates the detection of autoexec.bat to a
calling batch file.

Add the following line to autoexec.bat:

call your_batch_file %0

Then create a new batch file consisting of these lines:

@echo off
echo %1 | find /i "autoexec.bat" > nul
if errorlevel 1 echo autoexec.bat is not running
your_dos_program

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[alvinamorey@notmail.com]

On Mon, 26 Nov 2007 11:59:27 -0700, "Buffalo" <Eric@nada.com.invalid>
wrote:

>
>"Edward" <Edward@discussions.microsoft.com> wrote in message
>news:F7B763EF-93F2-4670-8B2B-E5CB5617569F@microsoft.com...
>> Well.. It's a very advanced question.. It will exercise your minds, and
>solve
>> my problem.. I thank very much who can help me.. (and forgive me for my
>poor
>> english)
>>
>> That's the question:
>>
>> I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY AUTOEXEC.BAT OR
>NOT.
>>
>> In another words: If autoexec is in execution or is finished.
>>
>> I tried this way:
>>
>> Inside the program I tried to modify or delete autoexec.bat. So, if I
>could,
>> autoexec is close and if I couldn't, it's open and then I'd have my
>answer...
>>
>> It didn't work, because even when it's running you can delete it, and at
>the
>> time to run the next command inside it, a message like "batch file is
>> missing" appears.
>>
>> So, I believe somewhere in memory the name of the batch file running is
>> storaged.
>>
>> Where is it?
>>
>> Does anybody have a different way to solve my problem?
>>
>> Thank you very much..
>>
>> Ed
>Perhaps you could just rename autoexec.bat to autoexec.bak or
>similar.
>At the C:\ prompt, type ren autoexec.bat autoexec.bak and press
>Enter.
>Reboot if you need to see if the 'storaged' program does or doesn't come
>up.
>If this causes problems, simply just rename autoexec.bak to autoexec.bat and
>press Enter. .
>

Some programs, even some older windows programs need the "path"
statement in autoexec.bat. I still use an old Win95 program called
"Microsoft Bob". If I dont keep it in the path, it wont work. I like
the program, but I think they could have fixed that path issue. How
hard is it to program something to find it's own files? Why didn't
they just put them in the same directory. I think they could have
gone somewhere with this prgm, but they screwed it up from the start.
It does work fine if the dir is in the path though.

 

[thanatoid]

alvinamorey@notmail.com wrote in
news:8dhmk3hki05a8juf4fs8f3odo8qg5gpqt8@4ax.com:

> On Mon, 26 Nov 2007 11:59:27 -0700, "Buffalo"
> <Eric@nada.com.invalid> wrote:
>
>>
>>"Edward" <Edward@discussions.microsoft.com> wrote in
>>message
>>news:F7B763EF-93F2-4670-8B2B-E5CB5617569F@microsoft.com...
>>> Well.. It's a very advanced question.. It will exercise
>>> your minds, and
>>solve
>>> my problem.. I thank very much who can help me.. (and
>>> forgive me for my
>>poor
>>> english)
>>>
>>> That's the question:
>>>
>>> I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY
>>> AUTOEXEC.BAT OR
>>NOT.
>>>
>>> In another words: If autoexec is in execution or is
>>> finished.
>>>
>>> I tried this way:
>>>
>>> Inside the program I tried to modify or delete
>>> autoexec.bat. So, if I
>>could,
>>> autoexec is close and if I couldn't, it's open and then
>>> I'd have my
>>answer...
>>>
>>> It didn't work, because even when it's running you can
>>> delete it, and at
>>the
>>> time to run the next command inside it, a message like
>>> "batch file is missing" appears.
>>>
>>> So, I believe somewhere in memory the name of the batch
>>> file running is storaged.
>>>
>>> Where is it?
>>>
>>> Does anybody have a different way to solve my problem?
>>>
>>> Thank you very much..
>>>
>>> Ed
>>Perhaps you could just rename autoexec.bat to
>>autoexec.bak or similar.
>>At the C:\ prompt, type ren autoexec.bat autoexec.bak
>> and press Enter.
>>Reboot if you need to see if the 'storaged' program does
>>or doesn't come up.
>>If this causes problems, simply just rename autoexec.bak to
>>autoexec.bat and press Enter. .
>>
>
> Some programs, even some older windows programs need the
> "path" statement in autoexec.bat. I still use an old Win95
> program called "Microsoft Bob". If I dont keep it in the
> path, it wont work. I like the program, but I think they
> could have fixed that path issue. How hard is it to
> program something to find it's own files?

Hey, it's a MICROSOFT program!

> Why didn't they
> just put them in the same directory. I think they could
> have gone somewhere with this prgm, but they screwed it up
> from the start. It does work fine if the dir is in the path
> though.
>

Actually, the path command was a pretty good idea, because it
allowed for configuring your system (i.e. putting things where
YOU wanted them to go) and also, primarily, saved a lot of time
with the directory/drive commands when in DOS.

Anyway, it's a line or two or three in the file, what's the big
deal?

BTW congratulations on being the first person I've ever "met"
who admits to using BOB.

Have you heard, there's a new version out! Only problem is you
need a 3GHz machine and 2MB of RAM to run it. It's called Vista.

 

[Edward]

Hi Franc
Thank you very much for your ideas. I loved the one where you combined echo
and find. I had never thought this way. And I didn't know either %0 returned
the name of command line. Good learnings for me.... But...

It works but don't solve my problem.

It's a kind of protection against copies I did for a x_program, and
x_program must run when PC starts without any interference of user. So, it
works like this, when PC starts:
1) In config and autoexec I create a virtual drive D: with ramdrive command.
2) my_dos_program unzips the program to drive D: using a password which
contains the HD serial number.
3) x_program starts imediately after extraction.

Once running, only ctrl-alt-del stops x_program and, of course, x_program
disappears with drive D:

So users can use but can't copy x_program. It only works in HD it was
installed because of pkzip password, and nobody can see x_program after
extraction, but running.

I know it's a very simple protection, but it was the best I could think.

My_dos_program has a copy of autoexec.bat. So, if you try to edit
autoexec.bat to not run x_program after extraction so as you can see it in
drive D, my_dos_program won't decompress x_program.

In fact, my_dos_program is two programs that run one after another in
autoexec.bat. If the second one not runs 0.5 seconds after the first one at
most, I think someone is trying to execute autoexec commands one by one in
line command, and my_dos_program won't decompress x_program.

Are you stil there? lol..

But, I believe a smart guy like you, would copy the 2 parts of
my_dos_program to a new batch file and.. tchan tchan !!! x_program will be
extract to drive D and be copied making me cry.. :-(........

That's the reason I want to know if my_dos_program was called by autoexec,
because in autoexec, x_program starts imediately after (I can't run x_program
within my_dos_program because of dos limited memory.)

So, your ideas were greats but they aren't enough to stop a smart guy, who
would analyze autoexec line per line. I also know, nothing stops a smart guy,
but I try to difficult his life as much as I can.

Thank you, Franc, even if you don't have more ideas for me..


"Franc Zabkar" wrote:

> On Tue, 27 Nov 2007 06:23:11 +1100, Franc Zabkar
> <fzabkar@iinternode.on.net> put finger to keyboard and composed:
>
> >On Tue, 27 Nov 2007 06:16:34 +1100, Franc Zabkar
> ><fzabkar@iinternode.on.net> put finger to keyboard and composed:
> >
> >>I don't know how to detect autoexec.bat directly, but you could test
> >>for a flag in an environment variable.
> >>
> >>For example, add these lines to autoexec.bat and then test for the
> >>existence of the environment variable, flag, within your program.
> >>
> >> set flag=%0
> >> your_dos_program
> >> set flag=
> >>
> >>%0 contains the name of the calling batch routine, in this case
> >>autoexec.bat.
> >
> >Another way is to call your program as follows:
> >
> > your_dos_program %0
> >
> >Then parse the command line arguments within your program.
>
> Here's a third way. It relegates the detection of autoexec.bat to a
> calling batch file.
>
> Add the following line to autoexec.bat:
>
> call your_batch_file %0
>
> Then create a new batch file consisting of these lines:
>
> @echo off
> echo %1 | find /i "autoexec.bat" > nul
> if errorlevel 1 echo autoexec.bat is not running
> your_dos_program
>
> - Franc Zabkar
> --
> Please remove one 'i' from my address when replying by email.
>

 

[Mike Jones]

Edward wrote:
> Well.. It's a very advanced question.. It will exercise your minds, and solve
> my problem.. I thank very much who can help me.. (and forgive me for my poor
> english)
>
> That's the question:
>
> I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY AUTOEXEC.BAT OR NOT.
>
> In another words: If autoexec is in execution or is finished.
>
> I tried this way:
>
> Inside the program I tried to modify or delete autoexec.bat. So, if I could,
> autoexec is close and if I couldn't, it's open and then I'd have my answer...
>
In the autoexec.bat check to see if %0 is set, if it isn't then this is
being run at boot time.

> It didn't work, because even when it's running you can delete it, and at the
> time to run the next command inside it, a message like "batch file is
> missing" appears.
>
> So, I believe somewhere in memory the name of the batch file running is
> storaged.
>
> Where is it?
>
> Does anybody have a different way to solve my problem?
>
> Thank you very much..
>
> Ed
>

 

[Mike Jones]

Franc Zabkar wrote:
> On Mon, 26 Nov 2007 04:34:00 -0800, Edward
> <Edward@discussions.microsoft.com> put finger to keyboard and
> composed:
>
>> Well.. It's a very advanced question.. It will exercise your minds, and solve
>> my problem.. I thank very much who can help me.. (and forgive me for my poor
>> english)
>>
>> That's the question:
>>
>> I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY AUTOEXEC.BAT OR NOT.
>>
>> In another words: If autoexec is in execution or is finished.
>>
>> I tried this way:
>>
>> Inside the program I tried to modify or delete autoexec.bat. So, if I could,
>> autoexec is close and if I couldn't, it's open and then I'd have my answer...
>>
>> It didn't work, because even when it's running you can delete it, and at the
>> time to run the next command inside it, a message like "batch file is
>> missing" appears.
>>
>> So, I believe somewhere in memory the name of the batch file running is
>> storaged.
>>
>> Where is it?
>>
>> Does anybody have a different way to solve my problem?
>>
>> Thank you very much..
>>
>> Ed
>
> I don't know how to detect autoexec.bat directly, but you could test
> for a flag in an environment variable.
>
> For example, add these lines to autoexec.bat and then test for the
> existence of the environment variable, flag, within your program.
>
> set flag=%0
> your_dos_program
> set flag=
>
> %0 contains the name of the calling batch routine, in this case
> autoexec.bat.
>
Normally it would, but I believe it isn't set at boot time.

> For much better answers I suggest you repost your question to
> alt.msdos.batch.
>
> - Franc Zabkar

 

[Mike Jones]

thanatoid wrote:
> alvinamorey@notmail.com wrote in
> news:8dhmk3hki05a8juf4fs8f3odo8qg5gpqt8@4ax.com:
>
>> On Mon, 26 Nov 2007 11:59:27 -0700, "Buffalo"
>> <Eric@nada.com.invalid> wrote:
>>
>>> "Edward" <Edward@discussions.microsoft.com> wrote in
>>> message
>>> news:F7B763EF-93F2-4670-8B2B-E5CB5617569F@microsoft.com...
>>>> Well.. It's a very advanced question.. It will exercise
>>>> your minds, and
>>> solve
>>>> my problem.. I thank very much who can help me.. (and
>>>> forgive me for my
>>> poor
>>>> english)
>>>>
>>>> That's the question:
>>>>
>>>> I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY
>>>> AUTOEXEC.BAT OR
>>> NOT.
>>>> In another words: If autoexec is in execution or is
>>>> finished.
>>>>
>>>> I tried this way:
>>>>
>>>> Inside the program I tried to modify or delete
>>>> autoexec.bat. So, if I
>>> could,
>>>> autoexec is close and if I couldn't, it's open and then
>>>> I'd have my
>>> answer...
>>>> It didn't work, because even when it's running you can
>>>> delete it, and at
>>> the
>>>> time to run the next command inside it, a message like
>>>> "batch file is missing" appears.
>>>>
>>>> So, I believe somewhere in memory the name of the batch
>>>> file running is storaged.
>>>>
>>>> Where is it?
>>>>
>>>> Does anybody have a different way to solve my problem?
>>>>
>>>> Thank you very much..
>>>>
>>>> Ed
>>> Perhaps you could just rename autoexec.bat to
>>> autoexec.bak or similar.
>>> At the C:\ prompt, type ren autoexec.bat autoexec.bak
>>> and press Enter.
>>> Reboot if you need to see if the 'storaged' program does
>>> or doesn't come up.
>>> If this causes problems, simply just rename autoexec.bak to
>>> autoexec.bat and press Enter. .
>>>
>> Some programs, even some older windows programs need the
>> "path" statement in autoexec.bat. I still use an old Win95
>> program called "Microsoft Bob". If I dont keep it in the
>> path, it wont work. I like the program, but I think they
>> could have fixed that path issue. How hard is it to
>> program something to find it's own files?
>
> Hey, it's a MICROSOFT program!
>
>> Why didn't they
>> just put them in the same directory. I think they could
>> have gone somewhere with this prgm, but they screwed it up
>> from the start. It does work fine if the dir is in the path
>> though.
>>
>
> Actually, the path command was a pretty good idea, because it
> allowed for configuring your system (i.e. putting things where
> YOU wanted them to go) and also, primarily, saved a lot of time
> with the directory/drive commands when in DOS.
>
> Anyway, it's a line or two or three in the file, what's the big
> deal?
>

You could create a runbob.bat

oldpath=%path%
path %oldpath%BOBpath
bob
path %oldpath%
set oldpath=


> BTW congratulations on being the first person I've ever "met"
> who admits to using BOB.
>
> Have you heard, there's a new version out! Only problem is you
> need a 3GHz machine and 2MB of RAM to run it. It's called Vista.

 

[Edward]

Thank you Mike
But I need to know it inside my program.
Thank you for your attention anyway..


"Mike Jones" wrote:

> Edward wrote:
> > Well.. It's a very advanced question.. It will exercise your minds, and solve
> > my problem.. I thank very much who can help me.. (and forgive me for my poor
> > english)
> >
> > That's the question:
> >
> > I NEED TO KNOW INSIDE A DOS PROGRAM, IF IT WAS CALLED BY AUTOEXEC.BAT OR NOT.
> >
> > In another words: If autoexec is in execution or is finished.
> >
> > I tried this way:
> >
> > Inside the program I tried to modify or delete autoexec.bat. So, if I could,
> > autoexec is close and if I couldn't, it's open and then I'd have my answer...
> >
> In the autoexec.bat check to see if %0 is set, if it isn't then this is
> being run at boot time.
>
> > It didn't work, because even when it's running you can delete it, and at the
> > time to run the next command inside it, a message like "batch file is
> > missing" appears.
> >
> > So, I believe somewhere in memory the name of the batch file running is
> > storaged.
> >
> > Where is it?
> >
> > Does anybody have a different way to solve my problem?
> >
> > Thank you very much..
> >
> > Ed
> >
>

 

[Franc Zabkar]

On Tue, 27 Nov 2007 12:40:14 GMT, Mike Jones <admin@127.0.0.1> put
finger to keyboard and composed:

>Franc Zabkar wrote:

>> For example, add these lines to autoexec.bat and then test for the
>> existence of the environment variable, flag, within your program.
>>
>> set flag=%0
>> your_dos_program
>> set flag=
>>
>> %0 contains the name of the calling batch routine, in this case
>> autoexec.bat.
>>
>Normally it would, but I believe it isn't set at boot time.

I added the following line to autoexec.bat ...

set test=%0

.... and saw that the following line was executed:

set test=AUTOEXEC

My environment, as seen from a DOS box, was as follows:

C:\WIN98SE>set

PROMPT=$p$g
winbootdir=C:\WIN98SE
PATH=C:\WIN98SEC:\WIN98SE\COMMAND
COMSPEC=C:\WIN98SE\COMMAND.COM
TEST=AUTOEXEC
TEMP=D:\temp
TMP=D:\temp
windir=C:\WIN98SE
CMDLINE=doskey

So you're partly right in that the file's .bat extension is not
captured.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Mike Jones]

Franc Zabkar wrote:
> On Tue, 27 Nov 2007 12:40:14 GMT, Mike Jones <admin@127.0.0.1> put
> finger to keyboard and composed:
>
>> Franc Zabkar wrote:
>
>>> For example, add these lines to autoexec.bat and then test for the
>>> existence of the environment variable, flag, within your program.
>>>
>>> set flag=%0
>>> your_dos_program
>>> set flag=
>>>
>>> %0 contains the name of the calling batch routine, in this case
>>> autoexec.bat.
>>>
>> Normally it would, but I believe it isn't set at boot time.
>
> I added the following line to autoexec.bat ...
>
> set test=%0
>
> ... and saw that the following line was executed:
>
> set test=AUTOEXEC
>
> My environment, as seen from a DOS box, was as follows:
>
> C:\WIN98SE>set
>
> PROMPT=$p$g
> winbootdir=C:\WIN98SE
> PATH=C:\WIN98SEC:\WIN98SE\COMMAND
> COMSPEC=C:\WIN98SE\COMMAND.COM
> TEST=AUTOEXEC
> TEMP=D:\temp
> TMP=D:\temp
> windir=C:\WIN98SE
> CMDLINE=doskey
>
> So you're partly right in that the file's .bat extension is not
> captured.
>
> - Franc Zabkar
Sorry, it seems they've fixed it - my statement holds for DOS 6.22 and
previous.

 

[Franc Zabkar]

On Wed, 28 Nov 2007 10:44:38 GMT, Mike Jones <admin@127.0.0.1> put
finger to keyboard and composed:

>Franc Zabkar wrote:

>> I added the following line to autoexec.bat ...
>>
>> set test=%0
>>
>> ... and saw that the following line was executed:
>>
>> set test=AUTOEXEC
>>
>>
>> So you're partly right in that the file's .bat extension is not
>> captured.
>>
>> - Franc Zabkar

>Sorry, it seems they've fixed it - my statement holds for DOS 6.22 and
>previous.

Actually, %0 reflects the calling command line, eg batfile,
batfile.bat, or BATFILE.

The fact that %0 reports AUTOEXEC rather than AUTOEXEC.BAT led me to
wonder whether I could fool COMMAND.COM into executing AUTOEXEC.EXE in
preference to AUTOEXEC.BAT at bootup. In fact this is exactly what
happens. Maybe the OP could exploit this behaviour ???

Alternatively, the OP could use the MEM.EXE command to locate the Data
segments associated with COMMAND.COM.

For example, after booting to the command prompt in real DOS mode I
see the following:

=====================================================
C:\mem /m command

COMMAND is using the following memory:

Segment Region Total Type
------- ------ ---------------- --------
00635 160 (0K) Data
0063F 5,728 (6K) Program
007A5 1,440 (1K) Environment
----------------
Total Size: 7,328 (7K)
=====================================================

If I execute the above command within AUTOEXEC.BAT I see an additional
Data segment:

=====================================================

COMMAND is using the following memory:

Segment Region Total Type
------- ------ ---------------- --------
00635 160 (0K) Data
0063F 5,728 (6K) Program
007A5 1,440 (1K) Environment
007FF 80 (0K) Data
----------------
Total Size: 7,408 (7K)
=====================================================

If I add the Debug command to AUTOEXEC.BAT I get the following (edited
for clarity):

=====================================================

C:\debug

-d 7ff:0 4f

07FF:0000 M@............X[
07FF:0010 ........m...0...
07FF:0020 ................
07FF:0030 C:\AUTOEXEC.BAT.
07FF:0040 AUTOEXEC....$^..
-q

=====================================================

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Jeff Richards]

Your first program could write a code word into AUTOEXEC.BAT as a parameter
for the second program, perhaps based on the date and time so it's different
with each run. Then, if the second program didn't get the correct code as a
command line parameter it would know that it (a) wasn't being run from
AUTOEXEC.BAT and (b) wasn't being run immediately after the first program.

Just be sure when you re-write AUTOEXEC.BAT that you do not alter the byte
position in the file of the next command to execute (ie, your second
program), and, of course, that you preserve whatever is in there in addition
to your programs.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Edward" <Edward@discussions.microsoft.com> wrote in message
news:A794FC84-695D-4B1E-8BB0-2E0A43F870F7@microsoft.com...
> Hi Franc
> Thank you very much for your ideas. I loved the one where you combined
> echo
> and find. I had never thought this way. And I didn't know either %0
> returned
> the name of command line. Good learnings for me.... But...
>
> It works but don't solve my problem.
>
> It's a kind of protection against copies I did for a x_program, and
> x_program must run when PC starts without any interference of user. So, it
> works like this, when PC starts:
> 1) In config and autoexec I create a virtual drive D: with ramdrive
> command.
> 2) my_dos_program unzips the program to drive D: using a password which
> contains the HD serial number.
> 3) x_program starts imediately after extraction.
>
> Once running, only ctrl-alt-del stops x_program and, of course, x_program
> disappears with drive D:
>
> So users can use but can't copy x_program. It only works in HD it was
> installed because of pkzip password, and nobody can see x_program after
> extraction, but running.
>
> I know it's a very simple protection, but it was the best I could think.
>
> My_dos_program has a copy of autoexec.bat. So, if you try to edit
> autoexec.bat to not run x_program after extraction so as you can see it in
> drive D, my_dos_program won't decompress x_program.
>
> In fact, my_dos_program is two programs that run one after another in
> autoexec.bat. If the second one not runs 0.5 seconds after the first one
> at
> most, I think someone is trying to execute autoexec commands one by one in
> line command, and my_dos_program won't decompress x_program.
>
> Are you stil there? lol..
>
> But, I believe a smart guy like you, would copy the 2 parts of
> my_dos_program to a new batch file and.. tchan tchan !!! x_program will
> be
> extract to drive D and be copied making me cry.. :-(........
>
> That's the reason I want to know if my_dos_program was called by autoexec,
> because in autoexec, x_program starts imediately after (I can't run
> x_program
> within my_dos_program because of dos limited memory.)
>
> So, your ideas were greats but they aren't enough to stop a smart guy, who
> would analyze autoexec line per line. I also know, nothing stops a smart
> guy,
> but I try to difficult his life as much as I can.
>
> Thank you, Franc, even if you don't have more ideas for me..

 

[Edward]

Great idea, Jeff.. Thank you.. I'll do it and tell you about the results
soon..


"Jeff Richards" wrote:

> Your first program could write a code word into AUTOEXEC.BAT as a parameter
> for the second program, perhaps based on the date and time so it's different
> with each run. Then, if the second program didn't get the correct code as a
> command line parameter it would know that it (a) wasn't being run from
> AUTOEXEC.BAT and (b) wasn't being run immediately after the first program.
>
> Just be sure when you re-write AUTOEXEC.BAT that you do not alter the byte
> position in the file of the next command to execute (ie, your second
> program), and, of course, that you preserve whatever is in there in addition
> to your programs.
> --
> Jeff Richards
> MS MVP (Windows - Shell/User)
> "Edward" <Edward@discussions.microsoft.com> wrote in message
> news:A794FC84-695D-4B1E-8BB0-2E0A43F870F7@microsoft.com...
> > Hi Franc
> > Thank you very much for your ideas. I loved the one where you combined
> > echo
> > and find. I had never thought this way. And I didn't know either %0
> > returned
> > the name of command line. Good learnings for me.... But...
> >
> > It works but don't solve my problem.
> >
> > It's a kind of protection against copies I did for a x_program, and
> > x_program must run when PC starts without any interference of user. So, it
> > works like this, when PC starts:
> > 1) In config and autoexec I create a virtual drive D: with ramdrive
> > command.
> > 2) my_dos_program unzips the program to drive D: using a password which
> > contains the HD serial number.
> > 3) x_program starts imediately after extraction.
> >
> > Once running, only ctrl-alt-del stops x_program and, of course, x_program
> > disappears with drive D:
> >
> > So users can use but can't copy x_program. It only works in HD it was
> > installed because of pkzip password, and nobody can see x_program after
> > extraction, but running.
> >
> > I know it's a very simple protection, but it was the best I could think.
> >
> > My_dos_program has a copy of autoexec.bat. So, if you try to edit
> > autoexec.bat to not run x_program after extraction so as you can see it in
> > drive D, my_dos_program won't decompress x_program.
> >
> > In fact, my_dos_program is two programs that run one after another in
> > autoexec.bat. If the second one not runs 0.5 seconds after the first one
> > at
> > most, I think someone is trying to execute autoexec commands one by one in
> > line command, and my_dos_program won't decompress x_program.
> >
> > Are you stil there? lol..
> >
> > But, I believe a smart guy like you, would copy the 2 parts of
> > my_dos_program to a new batch file and.. tchan tchan !!! x_program will
> > be
> > extract to drive D and be copied making me cry.. :-(........
> >
> > That's the reason I want to know if my_dos_program was called by autoexec,
> > because in autoexec, x_program starts imediately after (I can't run
> > x_program
> > within my_dos_program because of dos limited memory.)
> >
> > So, your ideas were greats but they aren't enough to stop a smart guy, who
> > would analyze autoexec line per line. I also know, nothing stops a smart
> > guy,
> > but I try to difficult his life as much as I can.
> >
> > Thank you, Franc, even if you don't have more ideas for me..
>
>
>

 

[Franc Zabkar]

On Thu, 29 Nov 2007 06:48:05 +1100, "Jeff Richards"
<JRichards@msn.com.au> put finger to keyboard and composed:

>Just be sure when you re-write AUTOEXEC.BAT that you do not alter the byte
>position in the file of the next command to execute (ie, your second
>program), and, of course, that you preserve whatever is in there in addition
>to your programs.

I can confirm this. In my case the autoexec.bat file is structured as
follows:

<stuff that executes before GUI starts>
win.com
<stuff that executes after GUI terminates>

If I add lines to the beginning of autoexec.bat whilst I'm in Windows,
then autoexec.bat breaks after shutting down the GUI.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.