 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Windows 98 / General Topics / November 2007Dos Batch File
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 > 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 [quoted text clipped - 25 lines] > > 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. . >> Well.. It's a very advanced question.. It will exercise your minds, and >solve [quoted text clipped - 39 lines] >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. >>> Well.. It's a very advanced question.. It will exercise >>> your minds, and [quoted text clipped - 53 lines] > 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. >>>> Well.. It's a very advanced question.. It will exercise >>>> your minds, and [quoted text clipped - 67 lines] > 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. 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 [quoted text clipped - 25 lines] > >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  SignaturePlease remove one 'i' from my address when replying by email. >I don't know how to detect autoexec.bat directly, but you could test >for a flag in an environment variable. [quoted text clipped - 8 lines] >%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 SignaturePlease remove one 'i' from my address when replying by email. >>I don't know how to detect autoexec.bat directly, but you could test >>for a flag in an environment variable. [quoted text clipped - 14 lines] > >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 SignaturePlease remove one 'i' from my address when replying by email. 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.. > >>I don't know how to detect autoexec.bat directly, but you could test > >>for a flag in an environment variable. [quoted text clipped - 30 lines] > > - Franc Zabkar 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. SignatureJeff Richards MS MVP (Windows - Shell/User) > Hi Franc > Thank you very much for your ideas. I loved the one where you combined [quoted text clipped - 51 lines] > > Thank you, Franc, even if you don't have more ideas for me.. Great idea, Jeff.. Thank you.. I'll do it and tell you about the results soon.. > 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 [quoted text clipped - 61 lines] > > > > Thank you, Franc, even if you don't have more ideas for me.. >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 SignaturePlease remove one 'i' from my address when replying by email. > On Mon, 26 Nov 2007 04:34:00 -0800, Edward > <Edward@discussions.microsoft.com> put finger to keyboard and [quoted text clipped - 42 lines] > %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 >> For example, add these lines to autoexec.bat and then test for the >> existence of the environment variable, flag, within your program. [quoted text clipped - 7 lines] >> >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:\WIN98SE;C:\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 SignaturePlease remove one 'i' from my address when replying by email. >>> For example, add these lines to autoexec.bat and then test for the >>> existence of the environment variable, flag, within your program. [quoted text clipped - 34 lines] > > - Franc Zabkar Sorry, it seems they've fixed it - my statement holds for DOS 6.22 and previous. >> I added the following line to autoexec.bat ... >> [quoted text clipped - 8 lines] >> >> - 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 SignaturePlease remove one 'i' from my address when replying by email. > 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 [quoted text clipped - 10 lines] > 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 [quoted text clipped - 10 lines] > > Ed Thank you Mike But I need to know it inside my program. Thank you for your attention anyway.. > > 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 [quoted text clipped - 28 lines] > > > > Ed |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.