anyway to get proc name through macro or other means

[ggodw000]

To aid in my debugging, I defined M_PRINTF macro that I use throughout my code. To further enhance it, I was wondering to see if there is a way to determine the proc name through manipulation of any of the pre-defined macro or any other means, so that, as of now, I can call M_PRINTF macro with string:

Code: Select all

M_PRINTF "\nBlah blah" 

and it prints out following output

Code: Select all

Blah blah

If I can automatically get proc name, so that when M_PRINTF macro called from any procedure, it is able to print something as follows:

Code: Select all

<procName>: Blah blah
<procName1>: Helloworld

when it is called from following proc-s:

Code: Select all

<procName> proc far
....
M_PRINTF "\nBlah blah"
....
<procName> endp

<procName1> proc far
....
M_PRINTF "\nHelloworld"
....
<procName1> endp

Sure, you can type manually in every M_PRINTF statement but that is huge maintenance nightmare, tedious and prone to errors and omissions.

I did this exactly in python using one of the python library, printing out calling function name in prefix automatiicaly with any print out is huge debugging clarity and assistance.

So far I looked through most comprehensive ASM X86 manual and looked through pre-defined macros so far, not finding anything.
Thanks.,

Here is my M_PRINTF macro which you can use to print any string on the fly without defining it on data segment and pass pointers to it:

it can currently process new line chars but i am planning to enhance further too:

Code: Select all

M_PRINTF MACRO pStr
    local skipStr, printfLoop, exitMacro, printfStr, m_printf_skip_esc_char
    IF      OPTION_ENABLE_M_PRINT
    push    ax
    push    dx
    push    bp
    push    cx

    jmp skipStr
    printfStr     db pStr, '$'

skipStr:
    lea     bp, cs:printfStr
    mov     cx, 3h

printfLoop:
    mov     ah, 02h
    mov     dl, cs:[bp]
    cmp     dl, '$'
    je      ExitMacro

    cmp     dl, '\'
    jne     m_printf_skip_esc_char
    cmp     byte ptr cs:[bp+1], 'n'
    jne     m_printf_skip_esc_char
    inc     bp

    mov     dl, 0dh
    mov     ah, 02h
    int     21h
    mov     dl, 0ah
    mov     ah, 02h
;   int     21h


m_printf_skip_esc_char:
    int     21h
    inc     bp
    dec     cx
;   jz      exitMacro
    jmp     printfLoop

exitMacro:
    pop     cx
    pop     bp
    pop     dx
    pop     ax
    ENDM
  

[iansjack]

Is a macro that calls DOS interrupts really useful in OS development? Or are you concerned here with just general purpose DOS programs?

Also note that your macro may trash the flags register, so it should be used with that in mind.

[alexfru]

Is there a way to at least get the line number if not the procedure name?

[Octocontrabass]

What assembler are you using? This kind of thing is specific to the assembler, and really has nothing to do with x86 at all.

NASM and YASM have the __FILE__ and __LINE__ macros, if that helps.

[ggodw000]

yes it might trash flags register, i need to take care of it.
i am using masm32.

[ggodw000]

Is a macro that calls DOS interrupts really useful in OS development? Or are you concerned here with just general purpose DOS programs?

i guess both. i am mostly writing in DOS to do some tools and experimental programs. so would be useful for some time.
can it be used in O/S dev? Can i use it while still in protected mode? that is million dollar question. I assumed yes once IDT initialized (which I am stil tackling) however i could be terribly wrong.

...currently i am launching my would-be kernel from DOS. later on, i will make it directly bootable but not a concern for now.
so dos interrupts 21h means, once DOS boots it installs those on IVT? if i boot directly without booting DOS, those int 21h will not be available?

[Octocontrabass]

i am using masm32.

Google says @FileName and @Line in MASM are roughly equivalent to __FILE__ and __LINE__ in NASM/YASM.

can it be used in O/S dev?

Only while you still have DOS. Once your OS loads without DOS, you can't use it anymore.

Can i use it while still in protected mode?

No. It only works in real mode. Once you're in protected mode, you'll have to write your own code to display information on the screen.

so dos interrupts 21h means, once DOS boots it installs those on IVT? if i boot directly without booting DOS, those int 21h will not be available?

Yes.

[ggodw000]

thanks!!!

[ggodw000]

would you mind giving technicalities/backgrounds on how int 21h DOS call will not work on full protected mode?
Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)
Also assuming that I will fully functional IDT which has translated every interrupt vector (total of 256) from IVT in real mode.

The only reason, I am going to pmode is to enough memory so that I can load as many exec.binary into memory as I wish, I actually contemplated using big-real mode but it is said big real mode can still not allow the CS to go above 64K so that will not work.

Thanks.,

[Brendan]

Hi,

Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)

Except, for most "modern" implementations of DOS (and things like "DOS inside Windows"), DOS either isn't in real mode at all, or isn't in real mode all of the time (e.g. various memory managers, like EMM386 that comes with MS-DOS, use protected mode internally). To work around that (for DOS applications that need protected mode) there were 2 APIs - one called VCPI and another called DPMI (which may or may not be built on top of VCPI).

The end result of all this is that you'd have to deal with multiple cases (and multiple work arounds with different APIs); and it's far easier to boot from "raw BIOS" than to put up with all the nonsense involved in attempting to boot from DOS in a reliable way.

Once you add the fact that the only benefit you get from using DOS is support for a crippled and antiquated file system that has poor performance, poor features, insane limitations and no security at all (that should never even be considered for any vaguely useful OS's main/root file system in the first place), the entire idea starts to look "incredibly less than smart". Then you add the fact that most potential end users haven't even seen a copy of DOS for about 20 years, and the idea ends up being more like "festering plague of idiocy".


Cheers,

Brendan

[ggodw000]

Hi,

Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)

Except, for most "modern" implementations of DOS (and things like "DOS inside Windows"), DOS either isn't in real mode at all, or isn't in real mode all of the time (e.g. various memory managers, like EMM386 that comes with MS-DOS, use protected mode internally). To work around that (for DOS applications that need protected mode) there were 2 APIs - one called VCPI and another called DPMI (which may or may not be built on top of VCPI).

The end result of all this is that you'd have to deal with multiple cases (and multiple work arounds with different APIs); and it's far easier to boot from "raw BIOS" than to put up with all the nonsense involved in attempting to boot from DOS in a reliable way.

Once you add the fact that the only benefit you get from using DOS is support for a crippled and antiquated file system that has poor performance, poor features, insane limitations and no security at all (that should never even be considered for any vaguely useful OS's main/root file system in the first place), the entire idea starts to look "incredibly less than smart". Then you add the fact that most potential end users haven't even seen a copy of DOS for about 20 years, and the idea ends up being more like "festering plague of idiocy".


Cheers,

Brendan

Yes, I totally understand, what I am doing is totally antiquated, it is 16-bit asm programming! However, I am not doing it to present and sell it to people, it is totally for learning. That being said, goal of my project was to design very minimal kernel that is able to load multi binary and implement multitasking kernel basis initially, once I get behind, I will perhaps discover and learn what the limitations is and may be work on to improve and optimize. So far, i can not even get started since it derailed several times, had to get pmode working and still need to get it working with the interrupt. Last few weeks it also had derailed and had to implement complete memory management module (that was going to be required anyways). So now, I'd rather not get bogged down on writing another video module if possible, rather would like to use easier approach on this aspect and use either DOS or BIOS services for it. .
So that is reason, for now, i am launching it from DOS for now. Now once launching from DOS, I am not loading any memory management, the kernel will take everything on its own at least in terms of memory. But for video services, would like to use int 21h if possible, if not what do you think of int10h BIOS services? I remember using int 10h, and if I remember corretly, it was bit more pain in the *ss than using int 21h. As long as it is technically possible to use either of these services from p-mode, I'd mind about the technical limitation and performance issues for now. If not, I was asking on technicality and how and why it would not work, in which case, I'd have no choice, well may be start working on some type of video module.

Now to spill my gut, this is the 2nd time i jump starting my project. few years down the road, i did all in real mode (that was the way university class has taught), but since there are just 1mb available only in real mode, the kernel will fail as soon as loads 2-3 loadable binary to do a task switch due to memory wrap-around.

[alexfru]

would you mind giving technicalities/backgrounds on how int 21h DOS call will not work on full protected mode,

They will work or will not work in exactly the same way as any other real-mode interrupts/code in protected mode. If you want both BIOS/DOS and protected mode, you need to run real-mode code in a virtual 8086 mode and you'll need to catch and reflect hardware and software interrupts belonging to that code back to that code from your kernel or whatever it is that you have. DPMI solves this.

Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)
Also assuming that I will fully functional IDT which has translated every interrupt vector (total of 256) from IVT in real mode.

The only reason, I am going to pmode is to enough memory so that I can load as many exec.binary into memory as I wish, I actually contemplated using big-real mode but it is said big real mode can still not allow the CS to go above 64K so that will not work.

Is it possible that DPMI is all you need? Btw, there's a ring 0 version of CWSDPMI, which will run your code in ring 0, which might be handy for some tasks.

[ggodw000]

would you mind giving technicalities/backgrounds on how int 21h DOS call will not work on full protected mode,

They will work or will not work in exactly the same way as any other real-mode interrupts/code in protected mode. If you want both BIOS/DOS and protected mode, you need to run real-mode code in a virtual 8086 mode and you'll need to catch and reflect hardware and software interrupts belonging to that code back to that code from your kernel or whatever it is that you have. DPMI solves this.

Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)
Also assuming that I will fully functional IDT which has translated every interrupt vector (total of 256) from IVT in real mode.

The only reason, I am going to pmode is to enough memory so that I can load as many exec.binary into memory as I wish, I actually contemplated using big-real mode but it is said big real mode can still not allow the CS to go above 64K so that will not work.

Is it possible that DPMI is all you need? Btw, there's a ring 0 version of CWSDPMI, which will run your code in ring 0, which might be handy for some tasks.

never dealt with virtual 8086 mode nor DPMI. Perhaps it is more straightforward to deal with video buffer directly. is that how kernels usually do? How about int 10h video services, would it be good idea to use it at all? if not, if not i am going to take a shot and try to do a video module. I think I am quite murky on these areas.