kevinro@microsoft.UUCP (Kevin ROSS) (05/01/90)
In article <4401@plains.UUCP> harlow@plains.UUCP (Jay B. Harlow) writes: >In article <273@caslon.cs.arizona.edu> roussos@cs.arizona.edu (George E. Roussos) writes: >>In article <1990Apr27.155908.4260@geac.com> mike@geac.com (Mike Sweet) writes: ||| I'm currently using OS/2 version 1.1 and managing to acieve code ||| overlays with DosCreateCSAlias. ||| [stuff deleted - how will this work on 32 bit OS/2]. ||| Anyone know the answer to this? (i.e. can I read code off the disc ||| into a piece of memory and then jump into it) [in 32 bit OS/2] ? Why the need for code overlays? If you are creating code on the fly, then DosCreateCSAlias will work. However, there is no such 32-bit function under OS/2 v2.0. The 16-bit version of the API will still work under 2.0. ||Someone please correct me if I am wrong, but in theory if a program is ||running under an OS that takes advantage of the 386 architecture, it ||does not need an overlay scheme to use code that can't be loaded into ||memory at run time. This is thanks to the built in hardware support ||for virtual memory in the 386. |Have you used OS/2 & the DosCreateCSAlias system call????. | |the DosCreateCSAlias is used to create an excutable alias to a data |segment, For it is bad 'karma' to go executing DATA (good sign of a |bug in your program). Now you have this routine that compiles a |'language' on the fly (imcremental compiling, speadsheets, graphing...) |that you have NO IDEA what the functions are going to be until |the user is running you program (god knows where & why). Executing a DATA segment isn't just bad Karma, it is not possible. CODE segments are all executable. You cannot write to them. DATA segments are marked as read/write, and cannot be executed. This is enforced by the chip. |yes OS/2 2.0 is suppose to use PAGED V.M. as oppose to SEGMENTED V.M. & |only support a 'flat'? 32bit address space (not sure if seperate I&D), |if you have seperate I&D, then you need to alias, because a data |address is different from a inst address in seperate I&D The I&D space is the same. Under v2.0, if you want to have the same functionallity as DosCreateCSAlias, then you would use the following constructs: ... // Make a variable for the function address (void * pfnAddr)(); // Allocate a region to create the code in. DosAllocMem(&(void *)pfnAddr,ulSize,PAG_READ|PAG_WRITE|PAG_COMMIT); // Call some routine that writes code into your region CreateSomeCodeFunction(pfnAddr); // Setup the memory as executable DosSetMem(pfnAddr,ulSize,PAG_EXECUTE); // Call your function pfnAddr(); I have never actually tried this, but it should work.
golding@saturn.ucsc.edu (Richard A. Golding) (05/03/90)
In article <4416@plains.UUCP> harlow@plains.UUCP (Jay B. Harlow) writes: > >I know Microsoft knows about Multics, OS/2 is patterned after it, unix >is also. rumor has it ;-) Microsoft is quite a number of people, some of whom know about Multics, some of whom don't. OS/2 isn't really patterned after Multics; it's just that almost all uniprocessor operating systems written since the early 1970's have been significantly influenced by Multics. Only recently have there been operating systems developed which break with the Multics model in lots of significant ways, and most of those are distributed systems. It's more reasonable to say that OS/2 is patterned after Unix, since that is the competition MS is trying to beat. (E.g. consider longnames.) I agree that the decision to support only a single flat address space is regrettable when compared with an ideal system, but there were some very good reasons to make the decision. Consider trying to make a segmented system completely Posix compatible -- and the money that Posix compatibility implies -- and the decision is understandable. -richard -- ----------- Richard A. Golding, Crucible (work) and UC Santa Cruz CIS Board (grad student) Internet: golding@cis.ucsc.edu Work: {uunet|ucscc}!cruc!golding Post: Baskin Centre for CE & IS, Appl. Sci. Bldg., UC, Santa Cruz CA 95064
kevinro@microsoft.UUCP (Kevin ROSS) (05/05/90)
In article <4416@plains.UUCP> harlow@plains.UUCP (Jay B. Harlow) writes: |In article <11790@portia.Stanford.EDU| dhinds@portia.Stanford.EDU (David Hinds) writes: || Because of Microsoft's choice of the unsegmented memory model, it is ||not possible for the OS to distinguish between user code and user data, || || In my opinion, Microsoft made a mistake in adopting the flat model. ||The 80386 finally did segments right - to where they are useful and don't ||get in the way. Segments support many more access control possibilities ||than pages. It seems like a waste to ignore this functionality. |I aggree with David, if Microsoft chose to 'COMPLETELY' drop segments |(ie a FLAT memory model, NO SMALL, & NO SEGMENTS AT ALL) in |OS/2 2.0, It would be a waste/shame to bother with OS/2. Why is it a waste? The functionality of segments just makes the world a much more complicated place, not to mention slower. By dropping segments, we have accomplished 3 very important goals: 1) Done away with segment loads Segment loads while in protected mode are VERY expensive. It takes at least 22 clocks just to load a segment register. This has already proven to be a major speed win. 2) Code size is smaller By using a flat memory model, you can use any of the registers to address any location in user memory. You don't need segment overrides use es:si, or ds:bp. Compilers become much easier to write, and the list goes on. 3) Made OS/2 programs portable to other architectures Someday in the not to distant future, OS/2 will run on other hardware platforms. By not messing around with segments, the source code will be very portable to other architectures. About the only true gain of keeping 32-bit segments would be the ability to allocate more that 4 gigabytes of memory. If you are using that much memory, you surely won't want to run on a 386!