Is CLI valid for applications in Windows?

In a VDM (aka DOS/real-mode/v86 emulation), you can do a CLI, and it'll be virtualized, but only for that DOS box. For a real Win32 application, it won't be allowed. You can do it in a device driver (although it's rather discouraged, for a few instructions it won't make any difference). Since you'll need a device driver anyway to hit the I/O ports, that might be your best bet.

The target system is a XYCOM VME system running Win2K, and the "I/O" boards in the VMEbus are memory mapped. The XYCOM support library returns a pointer to applications that they can use to access the boards in the VMEbus. So I don't have to be in a device driver to be poking at hardware in this instance. But that is bad news about the CLI being blocked. Thanks for the info.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Actually, that's not true.

There is something called a Win32 console application which is a Win32 console. You can't tell the difference between them just by looking at them, but if you're using MSVC V 6.0 or newer, one option you can choose is the console apps. Also, there are exclusitivity calls you can make to the Win32 kernel (forgot what they are off the top of my head, but it has to do with thread priority).

But as you said, one cannot access hardware directly. Everything is done through a virtual device driver, so there won't be direct access to nonstandards ports, or any ports for tha matter (everything is virtualized).

-->Neil

"Neil Bradley" schrieb im Newsbeitrag news: snipped-for-privacy@corp.supernews.com...

them,

Win32

virtualized).

If you are thinking of critical sections, they won't block interrupts. Blocking IRQs (and also other CPUs -> spinlocks) is only possible for kernel code, in other words device drivers.

But hey, it is not that complicated to do a driver that just implements this one function.

- Rene

Win32 console apps are clearly "real" Win32 apps. There are many non-GUI Win32 apps running on the typical Windows system - most of the services, for starters.

Setting high realtime thread priority can get you bumped ahead of just about any application, and all of the GUI stuff, for example, but will not prevent high priority kernel stuff (including interrupts) from running.

There's really no virtualization of the kind you see with VDMs with any sort of Win32 app, console apps included. There can be some, provided by specific device drivers, but it's not a general facility like the virtualization support in VDMs.

Actually you *do* have a device driver to provide the memory-mapping of the board into user space. What I assume you're telling me is that this drive is supplied by the vendor and you cannot modify it to add an Ioctl-type function to do this interrupt-disabled sequence you need. Perhaps an plea (or cash offering) to the vendor is in order.

Alternatively, you *can* write a new driver to perform this function, and, while it's definitely not playing by the rules, there's little on conventional x86 systems to prevent it from just hitting any memory locations it wants. So long as you can figure out the real memory addresses you need to hit (which, remember, will likely not be the same ones your application sees), you can just hit those directly. Again, you'll never get MS certification for a driver that doesn't properly claim its hardware first (and you can't, since the vendor supplied driver will have already done so), but it's likely to work on any x86 system that Win2K will run on. If you've got access to the DDK, the genport or mapmem sample drivers could be whipped into providing such a service without too much trouble. And frankly, mapmem may be the start of a replacement for the vendor driver.

Are you thinking of WDM drivers or Legacy kernel mode? Either way it looks a lot more involved than VxDs, which are the only Windows drivers I'm experienced with. Can you point me to an ultra-simple driver?

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Running the critical thread at priority level 31 should prevent (at least on NT4 on a single processor computer) any kernel processes from interrupting it. Of course, the interrupts will still get through.

Page faulting during the critical code can be avoided by prereferencing the code, data and stack space prior to executing the critical code.

Getting to priority 31, the process must be running in REALTIME_PRIORITY_CLASS and the thread priority must be increased to THREAD_PRIORITY_TIME_CRITICAL.

When running at such elevated priority levels, the number of instructions executed at that level should be kept to an absolute minimum.

Of course, the proper way of handling such critical sections is to go to kernel mode and disable the interrupts.

Paul

Well, the problem is that vast swaths of stuff can happen off interrupts, tons of stuff may get dispatched at something above IRQL_PASSIVE_LEVEL. Drivers often signal completion of asynchronous I/Os with an APC (which runs at APC_LEVEL). There's the clock, inter-processor communications, stuff running at DISPATCH_LEVEL... So yes, running at priority 31 will prevent you being preempted by any "normal" threads, kernel or otherwise, but I don't think it gets anywhere near the OPs requirements of guaranteeing a minimum delay in a series of I/O operations.

Thanks to all for the answers. In view of everything, I have decided to look for a way of not needed such close timing between the two operations. One operation was starting a duty-cycle generator by kicking off a timer-counter. The other operation was to software trigger a buffered block A/D operation. I need to see the current in the solenoid rise and then fall slightly as the plunger moves. The idea is to measure the time it takes the solenoid to pull in. With the DOS implementation, I could just assume that the beginning of the A/D buffer corresponded to the initiation of the solenoid drive, and so the the knee in the current waveform could be timed by reference to the beginning of the buffer. Now, in the Windows implementation, I will start the buffered A/D, then start the solenoid. Then, after enough data has been acquired, I will look through the A/D buffer for the first indication of a rise in solenoid current. That will be my reference for timing the knee in the current waveform. It will be a bit more signal analysis, but then I don't have to depend on the two operations starting at once.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Read the Time Stamp Counter (with the RDTSC instruction) just before starting the ADC and immediately after it. Start the timer and read the TSC for the third time. If all time readings are close enough, the sequence was not interrupted, if the time stamps are too far apart, discard the result.

Especially if these output signals are on a slow ISA bus, the starting of the ADC happened sometimes between reading 1 and 2 (you might assume that it happened in the middle of the period) and the start of the timer sometimes between reading 2 and 3 (possible in the middle), thus, you can get some kind of guess, what the actual time delay was between these events.

Paul

That's a good idea because 99.99% of the time, the two operations will be close together. However, automotive test engineers can get picky. I don't want to confuse them by having to repeat a test of their solenoids even once. There might be something about "first test performance" that would make the repeated test non representative of the part being tested. So I think I'll stick to finding the beginning of the current waveform from context.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)