16 bit Apps vs 32 bit Apps

Hello!
Hopefully, you will be fine. I have a question about the diffrence between 16 bit Applications and 32 bit Applications.
I am personaly a C programmer, but I thought that I shoudl ask the KINGS (I use KING for an Assmebly Language Programmer)
My question is that where is the diffrence between the two. If there is one, is it in terms of Speed or Size?
Hopefully, you will guide me!
Thanx
mohsinali

Comments

  • hi,

    16 bit applications use typiccaly use variables with 16 bits,which could hold values from 0 up to 2^16 (0..65535).this code runs on the older 16-bit machines (186er and earlier) as well as on newer machines.
    those applications are limited to 16 bit registers and get a slow-down on greater values.they could only pass 2 bytes a time from memory to cpu and via verce.and are limited to 1 mb memory,because of the addressing mode,which uses a virtual 20-bit address,coz 16 bits(which could address 64k) were not enough,even for the old dos-progs.

    32 bit applications use 32 bit variables as standart and could deal with greater numbers and could copy 32 bits at a time from mem to cpu-regs and back.they theoreticly could address up to 4gb (2^32 bytes).win32 is a common 32-bit enviroment.

    of coz you could mix elements of both types in a programm,exspecially in assembly.it is possible,for example to write a 16 bit dos-application which does 32-bit math or to uses 32-bit addressing under dos with a protected-mode extender,for example.

    in c you could see what application-type you have with

    sizeof(int)

    this is 2 under 16-bit-dos-applications and 4 in a winbloze 32-bit-enviroment.

    hope this clears things a bit


  • Also, in assembly, 32bit CPU registers have other names than coresponding 16bit registers, and 32bit CPU's have a few 32bit instructions. Also, 16bit apps can run on 32bit CPUs, and a few variations of 16bit CPUs (386SX, 486SLC) can emulate 32bit CPUs and run 32bit apps.
  • Dear Friends!
    I am very much thank full to you that you helped me out for this, What I have understand is that 16 bit Apps have difficulty in managing the memory, so they used the segment + offset shceeme becuase they has'nt enough space in their variables.
    But now what the 32 bit are , they handle whole memory in a bigger chunk. (Let me know whether I am right or wrong)

    Now my question is that how a segment and offset pair can be translated into a real address for a 32 bit compiler such as MSVC++?
    Let the Address is B800:0000, Now how we will handle this?
    Third thing is that an Assembly language programmer have the option to develop either a 16 bit App or 32 bitApp or it depends upon Assembler?

    Thanx

  • : Dear Friends!
    : I am very much thank full to you that you helped me out for this, What I have understand is that 16 bit Apps have difficulty in managing the memory, so they used the segment + offset shceeme becuase they has'nt enough space in their variables.
    : But now what the 32 bit are , they handle whole memory in a bigger chunk. (Let me know whether I am right or wrong)
    :
    : Now my question is that how a segment and offset pair can be translated into a real address for a 32 bit compiler such as MSVC++?
    : Let the Address is B800:0000, Now how we will handle this?
    : Third thing is that an Assembly language programmer have the option to develop either a 16 bit App or 32 bitApp or it depends upon Assembler?
    :
    : Thanx
    :
    :

    16bit apps use seg:offs scheme because there are not enough bits even in their CPU registers, not only their variables. 32bit apps still use this scheme
    A 32bit compiler does not translates seg:offs pairs into real addresses.
    It uses only the offs part, wich is 32 bits, for most of the instructions. The translation of the 48bit addresses used in 32bit CPU addressing of memory is mainly done by the CPU and the mechanism is not exactly intended for begginer applications developers. However 16bit CPUs running in real address mode use this formula to translate adresses:
    Addr = Seg*16 + Offs
    This is a particulary simple case. Addr in this formula is called the fizical address and is used by memory DIMM's hardware to acces memory locations.

    To cover the example you gave, I'll say than in 32bit CPUs the segment is not explicitly choosen by programmer. The B800 segment is most likely invalid unless the operating sistem happens to give it to you as your or other aplication's segment. Your program receives a segment when it is loaded by operating system. As I said, the compiler only uses the offset part. You can't just give to it an arbitrary segment (B800) and ask it to read memory. The operating system will terminate your program.

    All normal assemblers nowadays let you create 32bit apps.

  • Thanx for guiding me but now I have two more questions

    1...What are the terms Real mode and protected mode mean? And what is the diffrence
    2...I have Good skills of C programming and my question is that which is the best time to learn Assembly?
    Thanx


  • The Real Address Mode and Protected Address Mode define the CPU mode of operation. It is mainly concerned about how the CPU hardware generates the fizical address from the logical address used by program instructions. You know the formula for the Real Mode. In Protected Mode the the CPU is useing translation tables created by the operating system to generate the fizical address. The tables are named: Global Descriptor Table, Local Descriptor Table and Interrupt Descriptor Table.
    There is a lot of theory about them. They also allow the CPU to check each of the pointers used by instructions for simple validations and allow programs to have distinct memory spaces and use addresses that do not overlap with other programs' adresses.
    For the second question you can learn assembly whenever you want. You can learn assembly even if you are a begginer programemr. You don't have to choose betwwen Real and Protected Mode, if that was your question. Programs under Win32 (Windows 95 or later) are Protected Node programs. MS-DOS programs are generally Real Mode programs.
  • [b][red]This message was edited by xkgdiam at 2003-10-23 20:11:54[/red][/b][hr]
    [b][red]This message was edited by xkgdiam at 2003-10-23 20:11:18[/red][/b][hr]
    [pre]
    :
    : The Real Address Mode .....

    it's ok for what you say, please Answer this if you can,
    (beacuse you said somehow that you can't select 0xB800 segment...)
    i write a program(?) in C++ , win32 console application.
    in there isn't MK_FP(seg,off) macro, right (under win32) ?
    i have two macros of me that works fine under DOS,
    mkfp(seg,off) ((((long)seg)<<16)|off)
    mkint(high,low) ((((int)high)<<8)|low)
    when OS execute the following command :
    *(int far *)mkfp(0xb800,0x0000)=mkint(ATR,'k')
    then it hungs, until CTR+ALT+DEL, which close DOS window, and it's all ok (windows not crashed).
    is there any explanation about this ?










  • Hmm,a little confusing here,right?

    Ok,there are 2 typical ways for a appliction:

    1.under dos in real-mode.

    in this mode your application could access (nearly;) EVERY single byte within the address space (<1MB) for read and write.Thats why a dos-application easily could crash the whole system,because it even could access memory-locations where parts of the OS is loacated at.there is no possibility to check wether a memory-location contains save-executable code.in this mode you could write directly to video/text-memory and make changes OS and system-internal tables like the interrupt-vector-table.note that is possible to make dos-applications running in protected-mode,too,but thats only a tricky thing to access more than 1mb ram and doesnt realy use all the protected-mode features,i think.

    2. win32-application in real-mode
    in this mode you use only a 32-bit offset to access memory and the CPU calculates the physical-address in ram with some help of the tables created by the OS and the 16-bit-segment-address which is used for finding the correct entry in this tables.for example,many applications start at 0x0400000,but they all using different physical addresses in ram,but the same in 'logical' ram.there are complex mechanisms to validate memory-locations,so your application is not allowed to access memory areas it doesnt own.your application need special 'rights' to be allowed to read,write or execute something in memory.otherwise there occurs a protection-fault and the OS will close your application.

    in a win32-envirenment a real-mode-dos-program becomes a special segment where the real-mode is emulated by the OS,and evrything should work fine.
    the win32-console is a completly different thing,it looks like a dos-prompt on screen,but its a real 32-bit-protected-mode-win32-program using the same addressing and protection-mechanism like a application appearing in a win32-window,except it hasnt a window ;)
    so you couldnt access every byte in memory like the real-mode-dos-application could do.

    hope this helps a little...
  • [b][red]This message was edited by xkgdiam at 2003-10-25 20:19:53[/red][/b][hr]
    ..yes, that i think that too, under 32-bit windows OSes
    ..we are all under ProtectedMode,(its an our nowdays' fact...
    ..all is running under GOSes,(Goverment Operating System) or maybe
    ..an SOS,(Social Operating System),..........)
    ..
    ..i was running a program that switch to ProtectedMode (through Dos-Box)
    ..and the result was that i'm allready in that mode no matter if
    ..i check or not, the option 'Prevent MS-DOS from detecting Windows'
    ..i'll try to make some function to scan GDTR segment address
    ..i think RealMode Emulation pass through it
  • [BLUE]
    What a wonderfull explanation is that about memory access and the applications...
    I have the same question about Win 98 and 95 and Me whether they run in protected mode or in Real mode...
    Morover, the applications that were developed using 16 bit compilers, and use the Segment + Offset Addressing Scheme get executed under modren platforms?
    The Console Window that is shown with 32-bit console application is not in fact real console... But the question is that the older applications that were developed using 16-bit compilers and using Direct Video Memory Access still work... How this is tackled?
    Plus, In future, and in the contex of .NET Framework, are we will be banned to even touch the RAM?
    Reagards,
    MohsinAli
    [/BLUE]

  • ok,today all modern OSes (Win9x,WinME,WinXP,Linux,...) are true protected mode systems which are using all possible advantages of it.when you start a real-mode-application,the OS creates a command-prompt and uses this to 'map' the screen-output to it.nearly all possible real-mode-features and direct hardware-access are emulated.when your dos-program uses some gfx-mode instead of textmode,the prompt will be expanded over the whole screen.there exists a special fall-back-mode in modern CPUs,which is called Virtual86 (V86)-mode,which allows to simulate the real-mode-addressing-scheme.thats how Win9x runs DOS-programs,Im not sure bout WinXP,but it should emulate all the stuff itsself without any 16-bit segments at all.

    note that protected-mode not nessesary means 32 bits,ealier versions of windows (<Win95) where 16-bit OSes and uses protected mode to access more memory.also it is possible to access more memory within real-mode with some tricks,which are only working in REAL real-mode (and not in the emulated envirenment).protected mode simply means,that more than one process can run (virtualy) simultanly,and a hardware-implemented possibilty to hide the different addressing spaces of different processes from each other and providing some access-right-levels so that one process could crash without crashing the machine.
  • IIRC, Intel used a 20-bit addressing scheme instead of a 32-bit one because at that time no one thought an entire megabyte of RAM would be utilized, let alone 4GB. Additionally, the extra address lines would take up valuable board space.

  • No Windows version after 95 runs in real mode, except for a short period at boot time. Old applications that run in real or protected mode still run very well on Windows XP, with only minor exceptions. This is done with support from both the microprocessor, which supports the virtual 8086 mode, and the operating system, which implements a virtual machine.

    The access to video memory is by an old app is handle by windows within the display driver and the virtual display driver. The CPU interrupts the application at every memory access within an established range (which include the video memory) and passes control to the OS, which passes it to the virtual device driver. The display virtual device driver and the display driver do their job and draw in the correct position on the screen and then control passes back to the app. Remember that the drivers are OEM dependet.

    A program written for the net framework is going to be interpreted by a virtual machine resideing in the OS (like java is interpreted) and the fizical ram in not accessible in the way we think about it when writting in assembler or VC++ 6.0

    But those thing are not really accessible to everyone and are not really needed


Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories