Win32API for attribute in Int10h subfunction 9

Hi,

I am porting a 16-bit DOS code which uses the Interrupt 10h
subfunction 9 to Win32.
I am using the Win32API function FillConsoleOutputAttribute(..) and
WriteConsoleOutputCharacter(...) to replace Int10h( sub-func 9) which
writes a character with attributes to the console.
The 7th bit of the byte which goes into ah indicates a blinking
character. But FillConsoleOutputAttribute(..) does not support
blinking.
Any ideas on how to achieve the blinking functionality? I need it to
be extremely optmized.

Thanks,
Nihar

Pardon my ignorance as I have never looked at windows console apps, but could you tell me whether the console mode is a full screen text mode operation (using real old fashioned alpha modes) or is it really just a graphics mode that is made to look like text mode?

Hi,

The console is not full screen in my case (you can have it if u want). Yes its character mode. Check out Win32 console API in MSDN.

regards,
Nihar

If it is not full screen and co-exists on the screen with other windows or windows programs I don't think it could possibly be in text mode. None of the other programs would work. Text mode hardware video modes are quite different from all points addressable (graphics) modes. Windows must set up the appropriate font maps and copy them according to the attribute/ASCII code words. Without hardware support for blinking (as in text mode) that means the Windows software would have to do the blinking itself. The only wa y I can see that you do it (without hardware support) is to keep your own buffer which maps to the text on the screen. The buffer could be one word for each character displayed. The upper byte would be attribute one and the lower byte would be attribute two. Then every blink time you would have to check this buffer and for those words where the upper byte was not the same as the lower byte you would rewrite the corresponding text with the alternating attribute values. A lot of work, yes, but you could even make blinking between different colors and not just intensities as in standard DOS text modes. Of course, if there is hardware support somehwere....

Hi,
Thanks a lot for your detailed reply. You are right, its not exactly Text Mode as we think of. Windows "emulates" the Text mode to provide compatibility with old character mode programs.
<snip>
Consoles provide high-level support for simple character-mode applications that interact with the user by using functions that read from standard input and write to standard output or standard error.
<snip>
thats from MSDN.....
What you suggest seems to make sense at this time but I feel it would be very unoptimized!
Its really strange that with so many character based applications around, Windows doesnt have a simple mapping for blinking a character!
Is there any standard C function which does the blinking thing? I mean, this code uses an Interrupt to speed things up but there has to be some standard C function which blinks a character?

I don't know of any standard C function. It would also seem to be difficult to do with all the different hardware means of addressing video memory. I do recall graphics function libraries that came with certain C compilers in the older days but these were not standard. One seldom used them anyways as they often used VERY slow BIOS calls. In text mode it was so easy to write directly to the hardware (and so fast) that it was the method most commonly used. Then you did what you wanted with the attribute byte.

But if there is no hardware support (and I have never looked at the console API functions so I don't know) it looks like your stuck with doing it yourself. I just looked through a chapter on console applications and from what I can see things look bleak. It smells of Windows graphics API. For one thing, you call a function to set the text color and attribute once and then output the text. Just like setting the pen color and drawing the line using the windows graphics API. In real text mode you simply set the attribute and ASCII code of the word and then wrote that word to video hardware. Each symbol output could then easily (very fast) have it's own unique color and background. Now you have to call the set color/attribute function followed by the text out function. To blink you are simply going to have to write to the graphics screen. It almost seems like that would be easier to do using Direct X and a 256 color mode and changing the pallete. Its the only fast way I know of do do blinking in graphics modes. In graphics modes without pallettes it seems you are stuck with updating video memory. Sorry, I have no solution.

By the way, wasn't there more to this blinking bit in the old text modes? In monochrome, bit 7 = 1 would blink but in color modes one had a choice. The lower four bits were the text color and the upper four bits were either the background color (including intensity) or just the three lower bits of the upper 4 (confusing, eh?) were the background and then bit 7 was blinking. So you could not have a blinking character with a high intensity background color. It was one or the other. I recall that one had to set a bit in another register on the video card to make that selection. It's been a long time! It looks like Windows decided to take the non blinking selection (which is MUCH more compatible with its GUI API functions).

Yeah it seems Microsoft took the easy way out!
I checked out a lot of Console mode applications on the net and none of them have any blinking character!
check out http://www.foxitsoftware.com/wac/toolkit_intro.htm
Heres the bit pattern of the attribute on the color monitor

0 Blue Foreground
1 Green "
2 Red "
3 Highlight Foreground
4 Blue Background
5 Green "
6 Red "
7 Blinking Foreground

I was thinking on the lines of DirectX. But I have never ever touched DirectX programming! Can you point me to the right resources from where I can start off?

Unfortunately I am equally as new with Direct X. Just starting it. But if you are going to do that is it worth it staying with console operations? I was only thinking of it since that is the only way I know of to get hardware support of blinking via setting palletes (fast). Of course it effects all values of the pallette numbers changed.

Why not just try resetting the values of the text at the rate you desire blinking? If you blink every half second (or longer) the overhead may not be so bad, but as with all black box functions I have no idea how the API functions actually do their job.

If you have a buffer mirroring the text on the screen with the attributes you want, every blink period you just redraw the text setting the appropriate color values. If the 'FillConsoleAttribute()' function is smart enough to do just sections of the screen then life would be even easier.

I have to stick to the console coz the client demands it. Will have to further discuss with him regarding the pros and cons.
These are just a few lines I'm planning to pursue. DirectX, Device Driver, having a low priority thread running which will change the character property and mimic the blinking. Lets see what comes up.

Using Direct X you can easily set a full screen video mode (I don't know if you need multiple console apps; most DOS apps were not made for multiple runs). What I don't know is if you can set a REAL text mode. Probably not, but it would make life easier for you if you could!

By the way, do you remember what register you had to set to go from blinking to instense background colors in color modes? I think that blinking was the default but I know that I used it once to make black text on a BRIGHT white background.

Nopes dont know that! You can say, I was kindoff born and brought up in Windows ;) so my knowledge is limited! Although I have done a few courses on microcontrollers and processors during my eng. college days so am able to find my way!
BTW I got that blinking thing running in a standalone program using a thread.

Well thats good to hear. But it also shows that you have to and are programming with the Windows graphics API. Its funny your customer doesn't want it in regualr Windows format. One loses little.

In any case, knowing that register isn't going to help you because Windows will never let you access it anyways.

Thats the whole point of the project. I only have to port the 16-bit code to 32-bit using the Win32API. he code is a "library" code, on top of which a large number of applications have been made. So porting it to use the Windows GUI will be a different project altogether which I believe he has in pipeline. The current port will only help him overcome the 640K memory limitation and give him some performance benefit coz ntvdm will not come into picture.
Yup, Win32 will not allow me touch the hardware!

Coming to hardware, the code consists of a lot of code which does efficient memory management. For eg. there is code which "defragments" the memory.
for eg. lets say, if you have 100 bytes of total memory :D

1. u allocate 20 bytes.
2. u allocate another 70 bytes. DOS will give u the contiguos memory blocks.
3. You release the first 20 bytes.
4. Now if you ask for 40 bytes, DOS will say NO coz there are no 40 contigous bytes of memory!

The memory allocation routines in the code my_alloc() actually shifts the 70 bytes to the start and thus allows for 50 contiguous bytes.

I blv all this wont serve its purpose in Win32 because NT does not give you direct access to hardware. What you get as pointer to memory, does not point to the actual memory locations. Its just points to a table which is maintained by the OS.

I'd appreciate your comments on this.

BTW this could qualify for a new thread on the grp!