shutting down windows multitasking from PB/Dos

[Dan Symonds]

Gentlemen:
I have developed a piece of software that needs to be able to
assure 100% CPU resources during certain parts of the software
cycle. Is this achievable and if so then where do I start to
find the info on it.

Thanks
Dan Symonds


------------------

[Matthew Berg]

Not possible for a DOS application to have that degree of control over its own execution in a DOS VDM under Windows. If a DOS application needs to be assured of things like access to CPU resources, accurate timing, etc. then don't run it under Windows.

Is it not possible for you to recast your DOS application as a Windows console application?

------------------
If you try to make something idiot-proof, someone will invent a better idiot.

[This message has been edited by Matthew Berg (edited October 31, 2002).]

[Dan Symonds]

Matthew:
I have given consideration to porting the code over to CC but it
doesn't seem to give me the same access to the parallel and serial
ports that I currently need. Perhaps I have just misinterpreted the
code explanations but that's my current thought.

As far as the shutting down of Windows multitasking, I kinda figured
that it wasn't possible but needed some expert verification of such.

Thanks
Dan


------------------

[Paul Dixon]

Dan,
try adding !cli before and !sti after the critical code.

This clears and sets the interrupt enable flag. When cleared, Windows cannot interrupt your code so your code has 100% cpu time although there may be other side effects which are not desirable.

Win98 allows this, other versions may prevent the flag being changed.

Try to keep the time interrupts are disabled to a minimum.

Paul.





------------------

[Tom Hanlin]

paul, if i remember correctly, cli/sti have no effect on windows
multitasking, from at least win95 on up.

dan:
http://www.powerbasic.com/support/pb...read.php?t=421

------------------
tom hanlin
powerbasic staff

[Paul Dixon]

Tom,
I'm sure !cli used to work when I had Win98 but I now have Win98SE and it doesn't work anymore. That could account for some strange behaviour in one of my programs!

Paul.


------------------

[Dietmar Harlos]

Maybe this is of some use in your code. I have found it in Ralf Brown's Interrupt List, but didn't tested it yet.

INT 2F - MS Windows 3+ - BEGIN CRITICAL SECTION
        AX = 1681h
Notes:  used to prevent a task switch from occurring
        should be followed by an INT 2F/AX=1682h call as soon as possible
        nested calls are allowed, and must be followed by an appropriate number
          of "end critical section" calls
        not supported in Windows/386 2.x. Get INDOS flag with INT 21/AH=34h and
          increment by hand.
SeeAlso: AX=1682h,INT 15/AX=101Bh,INT 21/AH=34h


INT 2F - MS Windows 3+ - END CRITICAL SECTION
        AX = 1682h
Notes:  not supported in Windows/386 2.x.  Get InDOS flag with INT 21/AH=34h
          and decrement by hand, taking care not to decrement InDOS flag
          through zero
SeeAlso: AX=1681h,INT 15/AX=101Ch,INT 21/AH=34h

[Joep van Steen]

Hello,

And do you want to have Windows running? Because otherwise you could use
the method PowerQuest's DriveImage used previously:

1.
Back up the autoexec.bat and config.sys. Then they basically edited the autoexec.bat and config.sys
Key is adding the line DOS=SINGLE to the config.sys, instead of booting the
Windows GUI, the command prompt only will load after a reboot.

The autoexec.bat should run your app, and you need to restore the backed up autoexec.bat end config.sys.

2. reboot

3. run your app and clean up mess (restore autoexec and config)

4. when done, reboot (back to Windows.)

Note: This works in Windows 95, 98 but not in ME, you can make it work in ME by patching io.sys, command.com and regenv32.exe. In NT based operating system this can never work.

Best regards,
Joep



------------------
Joep

http://www.diydatarecovery.nl

[Dan Symonds]

Gentlemen:
Thank you for your replys. I have tried several of the suggested
solutions and have decided to place the software on a dos boot disk
as that completely removes any question. Since the software is
designed to be the only function running on a given system anyway,
it doesn't limit the users function any more than it normally would.

The proliferation of "advancements" in the windows operating system
seems to create more and more problems for those people that truly
need to be able to operate 'realtime'. I suppose that given time, I
could migrate to other programming languages that would enhance my
ability to contol the hardware more easily but as a designer of systems
as well as the programmer of the systems, my focus is on using tools that
I know and understand to be able to get time critical applications to
market. The help of this forum has be of great assistance to my
goals.

Many thanks
Dan Symonds
Mfg. Engineer
Varel International

------------------

[Joep van Steen]

Hello,

In my case I run XP and use PB3.5 DOS where my program frequently make BIOS calls. XP prohibits this. So, I compile an exe, boot a floppy and test. Floppy is okay but really slow when you have to do this a lot. So I am working on a system where I can boot a virtual partition. The virtual partition is nothing else than a image of a bootdiskette, I then look for a contiguous block of unused clusters on the harddisk where I can write the diskette image to. As a next step I backup current partition tables to spare sector in track 0 (of course it has to be verified if the sector is empty, I use LBA sector 30 for the purpose), and also add an entry which points to my virtual diskette. This is all done from a win32 executable. I then reboot the PC, the new MBR code loads and presents a menu where either the existing XP install can be selected, or the virtual boot disk. The virtual bootdisk boots straight in to a DOS environment. It's a lot quicker than booting a floppy.

The first thing that runs when booting the 'virtual' floppy is a DOS executable that restores the original MBR, so up on next reboot everything is back to normal.

This project is in its early stages and a lot of stuff that I want to run automatically is still done by hand using a disk editor. The concept works though.

I am used to reading and writing disk sectors from DOS using the int13h ext interface using code Sebastian Groenveld provided. From Windows it's a different beast though and all this WinApi stuff still confuses the heck out of me (see thread reading disks in PBCC forum). I would really appreciate of someone could explain me how to set the file pointer once I have opened \\.\PhysicalDrive0 ... code would be best. Once I ahve the code to read write I can manage as I do know my way around in partition tables etc..

Joep


------------------
Joep
http://www.diydatarecovery.nl

[This message has been edited by Joep van Steen (edited November 08, 2002).]

[Matthew Berg]

I have tried several of the suggested solutions and have decided to place the software on a dos boot disk as that completely removes any question.

Be aware that when distributing software on a "DOS boot disc" that you do not "system format" these discs using MS-DOS® or otherwise include any files, system or otherwise, from an MS-DOS® distribution (Permission: Use of Software).

For an alternative, try FreeDOS.

------------------
If you try to make something idiot-proof, someone will invent a better idiot.

[This message has been edited by Matthew Berg (edited November 10, 2002).]

[Dan Symonds]

Matthew:
Thank you for the advise. I will check out free dos immediately.

Dan


------------------