Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronic Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

DO*S to U$nix C environment

Status
Not open for further replies.

efundas

Member level 3
Joined
Jul 28, 2001
Messages
62
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
387
DO*S to U$nix C

I have some C programs which were used in DOS environment. Now I want to use these C programs in Unix environment. When I use them I am getting a totally a different result. My guess was that the data format ie, little indian and big indian is the cause for the wrong results, but I am not sure, can anyone confirm this. If so then is there any tool through which I can convert my DOS based C code to unix based c code.
 

Darkseed

Member level 2
Joined
Nov 30, 2002
Messages
50
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
410
Check that all constants are type defined. I mean, specify its type. For example:

#define some_constant 5L

Also verify all types (int, long, etc) are defined with the same number of bytes in your DOS and UNIX compilers.

I remember that in the C newsgroup Faq was this issue very well comented. Look for it.

Nevertheless, as a last resort you can always use dosemu...
 

Jørd

Junior Member level 2
Joined
Aug 9, 2001
Messages
22
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
156
The major problem won't be endian-ness (unless your unix machine uses a non-intel processor architecture) but merely the migration of 16-bit-code to 32-bit-code. The "processor" used on machines running DOS, the awful 8086, used to split memory in segments, each one being 64k in size and being nearly the same as the next one, merely shifted by 16 byte.
Thus the segmented address 0x1230:0x0010 is effectively the same address as 0x1231:0x000
or 0x122F:0x0020

Due to this fucked-up memory addressing scheme, 16-bit 8086 applications did some really strange stuff, which is difficult to port to machines having "straight" non-segmented memory access.
 

Status
Not open for further replies.
Toggle Sidebar

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top