Need to know parameter format for a Call function?

[Will1]

It sounds to me like your ADAM would be a candidate for backend storage for a relational database. Each ADAM file might make a good backing store for a single RDBMS table. You could then add additional code in a layer on top of ADAM, that would handle the relationships between tables.

Exactly. SQL does have the ability to establish relationships but it is cumbersome and could be done more efficiently by a program.

Segment registers are not accessible under any modern operating system, and that fact is quite irrelevant to application programmers. Many hardware platforms don't even have segment registers. Even more to the point, why would you need to? Learn to write modern software, and you'll be much better off. You seem to be stuck in a DOS mode of thinking in regard to programming. DOS programming (especially low level) concepts are largely irrelevant to modern programs.

The reason they are not available under WINDOWS is because MicroSoft didn't want them to be available to applications programs. WINDOWS uses them otherwise it wouldn't be able to address 32 Gigabytes of memory. (more recently 64 Gigabytes) Microsoft is on a path to destroy any control of the hardware that now remains in applications programmers' hands like it did under DOS. One example of that is "Full Screen Mode" which MicroSoft did away with an applications programmer's ability to use in Windows 7. It allows the applications programmer full control of the monitor screen. It still can be used under WINDOWS XP. Anybody with any real intelligence can see MicroSoft's aim to take over all applications programming of PCs. Back in the late 1990s, when the courts attempted to put a leash on MicroSoft's ability to monopolize the PC program market, they didn't realize that MicroSoft could stop the competition by doing away with programs' ability to control the hardware. MicroSoft don't want a program, like I've written, that uses the full screen to run on newer versions of WINDOWS. I'll be glad to send a copy of a system that uses "Full Screen Mode" to anyone who has a desktop running WINDOWS XP or an older version of WINDOWS. (I do have a WINDOWS 7 version of the system but I had to drop the mouse and graphics support of it because MicroSoft did away with that function on WINDOWS 7.)

[laserlight]

SQL does have the ability to establish relationships but it is cumbersome and could be done more efficiently by a program.

SQL does not establish relationships; the relationships are established in the domain modeling by human beings, which is then declared by these people by the use of SQL. Thus, it is the program that implements the relationships that were established, with SQL as the language telling the program what is the desired outcome. There is nothing cumbersome about this, since no matter what you do, you have to go from the drawing board into software.

[Will1]

SQL does not establish relationships; the relationships are established in the domain modeling by human beings, which is then declared by these people by the use of SQL. Thus, it is the program that implements the relationships that were established, with SQL as the language telling the program what is the desired outcome. There is nothing cumbersome about this, since no matter what you do, you have to go from the drawing board into software.

Don't be so "Nit-Picking" about how I describe things. Of course the programmer has to "establish" the relationships of a data base. SQL is then used to implement them. ADAM could certainly do that more efficiently than SQL.

[Codeplug]

>> Under WINDOWS, unlike under DOS, you can only have one ADAM file open at any given time.
>> Because under Windows the memory that your program uses has to be defined at compile time rather than acquired at execution time like ADAM does under DOS.
To me, that sounds like "you can only have one ADAM file open per process", since each process has their own unique virtual address space - but that's just a guess.

It would help me to understand things if I know how a Win32 C/C++ program would interface with ADAM (at a high level).
Is all the code in object/lib files that are linked directly into the exe?
Or is there an "ADAM.dll" with an interface header (.h) and lib?

All your code is created with a 32/64 bit compiler/assembler/linker that targets Win32 - correct? (Nothing uses 16/32 bit dos real mode stuff?)

>> The reason they are not available under WINDOWS is because MicroSoft ...
It sounds to me like you should blame Intel for protected mode. However, every modern OS requires this type of functionality.

The type of hw access that DOS allowed is still a requirement in many embedded applications - some still using some form of DOS today.

Memory Limits for Windows and Windows Server Releases (Windows)

gg

[Elkvis]

The reason they are not available under WINDOWS is because MicroSoft didn't want them to be available to applications programs. WINDOWS uses them otherwise it wouldn't be able to address 32 Gigabytes of memory. (more recently 64 Gigabytes) Microsoft is on a path to destroy any control of the hardware that now remains in applications programmers' hands like it did under DOS. One example of that is "Full Screen Mode" which MicroSoft did away with an applications programmer's ability to use in Windows 7. It allows the applications programmer full control of the monitor screen. It still can be used under WINDOWS XP. Anybody with any real intelligence can see MicroSoft's aim to take over all applications programming of PCs. Back in the late 1990s, when the courts attempted to put a leash on MicroSoft's ability to monopolize the PC program market, they didn't realize that MicroSoft could stop the competition by doing away with programs' ability to control the hardware. MicroSoft don't want a program, like I've written, that uses the full screen to run on newer versions of WINDOWS. I'll be glad to send a copy of a system that uses "Full Screen Mode" to anyone who has a desktop running WINDOWS XP or an older version of WINDOWS. (I do have a WINDOWS 7 version of the system but I had to drop the mouse and graphics support of it because MicroSoft did away with that function on WINDOWS 7.)

I think you're confused about a few things.

1. Windows does not deny access to hardware. It simply abstracts it into a consistent interface, controlled by security privilege levels. All modern operating systems do this, including every open source system, including Linux, FreeBSD, and many others. If you want direct access to the hardware, write a driver that interfaces with windows in its driver subsystem or write your own OS kernel. Direct access to hardware by application programs threatens the stability of the system, and the security of the user's data. Imagine what could happen if any program could read raw data from the hard drive or intercept network traffic from the network adapter. It's would be stupid to permit that kind of activity from unprivileged applications.

2. Microsoft does not want to monopolize all PC software. Why would they offer development tools and publish their API documentation if that was their intent? Your argument is ridiculous and reeks of trolling.

3. Full screen mode is still available, although it's generally associated with DirectX and graphical applications, although a full screen text console could be made to work as a layer on top of DirectX.

[laserlight]

Don't be so "Nit-Picking" about how I describe things. Of course the programmer has to "establish" the relationships of a data base. SQL is then used to implement them. ADAM could certainly do that more efficiently than SQL.

My nitpicking is because you state that "it is cumbersome and could be done more efficiently by a program", as if in one case it is not done by a program. Rather, in both cases it is done by a program. As for doing that more efficiently: if you agree that "your ADAM would be a candidate for backend storage for a relational database", then that would not be true since we can match ADAM simply by using ADAM to implement the backend storage for a relational database. You're comparing the wrong thing here, and your insistence in using "SQL" when you mean a relational database system does you a disservice.

[Will1]

>> It would help me to understand things if I know how a Win32 C/C++ program would interface with ADAM (at a high level).
Is all the code in object/lib files that are linked directly into the exe?

EXACTLY!

All your code is created with a 32/64 bit compiler/assembler/linker that targets Win32 - correct? (Nothing uses 16/32 bit dos real mode stuff?)

The DOS version was created with a DOS (16 Bit) Assembler and Link Edit system. I wrote (converted) it to run under WINDOWS with a MASM 32 Assembler and Link Edit system.

>> The reason they are not available under WINDOWS is because MicroSoft ...
It sounds to me like you should blame Intel for protected mode. However, every modern OS requires this type of functionality.

I don't "blame" anybody for "protected mode." Protected Mode is not the problem. I programmed the IBM mainframe, which has protected mode, starting in 1965. Being banned from using the "Segment" registers is the problem. If IBM had banned programs from using the 16 general purpose 32 bit registers that it has had since the 1960s, they would have had as lame Operating Systems as modern PCs have. I programmed the first version of ADAM before WINDOWS was even thought of. If WINDOWS had allow user programs to (completely) control their usage of 4 Gigabytes of (protected) memory, using the "Segment" registers to address it, It would have made the problem of converting DOS ADAM to WINDOWS32 ADAM a simple job and WINDOWS32 ADAM would have been much more powerful than it is.

The type of hw access that DOS allowed is still a requirement in many embedded applications - some still using some form of DOS today.

Maybe that's how I should implement ADAM to the newer Operating Systems?

[Will1]

I think you're confused about a few things.

1. Windows does not deny access to hardware. It simply abstracts it into a consistent interface, controlled by security privilege levels. All modern operating systems do this, including every open source system, including Linux, FreeBSD, and many others. If you want direct access to the hardware, write a driver that interfaces with windows in its driver subsystem or write your own OS kernel. Direct access to hardware by application programs threatens the stability of the system, and the security of the user's data. Imagine what could happen if any program could read raw data from the hard drive or intercept network traffic from the network adapter. It's would be stupid to permit that kind of activity from unprivileged applications.

2. Microsoft does not want to monopolize all PC software. Why would they offer development tools and publish their API documentation if that was their intent? Your argument is ridiculous and reeks of trolling.

3. Full screen mode is still available, although it's generally associated with DirectX and graphical applications, although a full screen text console could be made to work as a layer on top of DirectX.

Sure Elk! I could just sit down for thirty minutes and write an Operating System. There is already an Operating System that IBM called OS/2 that is superior to WINDOWS and Linux. I have been in contact with Mensys (the company that IBM turned OS/2 over to) but they don't have the source code for it and IBM says that the source code has been lost.

[Elkvis]

I don't "blame" anybody for "protected mode." Protected Mode is not the problem. I programmed the IBM mainframe, which has protected mode, starting in 1965. Being banned from using the "Segment" registers is the problem. If IBM had banned programs from using the 16 general purpose 32 bit registers that it has had since the 1960s, they would have had as lame Operating Systems as modern PCs have. I programmed the first version of ADAM before WINDOWS was even thought of. If WINDOWS had allow user programs to (completely) control their usage of 4 Gigabytes of (protected) memory, using the "Segment" registers to address it, It would have made the problem of converting DOS ADAM to WINDOWS32 ADAM a simple job and WINDOWS32 ADAM would have been much more powerful than it is.

Perhaps you could explain why you need the segment registers. In modern operating systems, you're given a code segment, a stack, and a data segment. There is no reason to manipulate the segment registers to access these things. If your code requires the manipulation of the CS, SS, DS, ES, FS, etc. registers, then it probably isn't suitable to run on modern operating systems. You should think about converting it to work within the operating systems on which it's likely to run. The memory in protected mode is not segmented in the way that DOS real mode memory was. You don't have a new segment every 16 bytes like real mode and DOS have. On x86 and x64 platforms, in protected mode, segments are logical constructs (in a very similar way to logical tables in an RDBMS) that have a physical (virtual when paging is enabled - on all modern operating systems, it is) base and size. A segment's selector (roughly analogous to real mode segment numbers) is an index in a table that contains segment descriptors, which describe the physical or virtual base address, the size, and a number of other parameters. They bear little to no resemblance to segments in DOS or real mode. Sequential descriptors in the GDT/LDT (global and local descriptor tables, respectively) need not represent adjacent memory regions, for example. They can represent any arbitrary region in memory.

[Elkvis]

Sure Elk!

You haven't been here long enough or developed a sufficient reputation to refer to me in such a casual way, especially since I can tell from the tone of your post that you meant it in a more-or-less derogatory way. Please refrain from doing this.

There is already an Operating System that IBM called OS/2 that is superior to WINDOWS and Linux.

A very subjective and specious claim, particularly given the fact that OS/2 was never developed after about 1996, and was never accepted as a legitimate operating system. I'd need to see supporting objective evidence to even further acknowledge your claim. Comparing it to Linux is like comparing a Geo Metro to a Bugatti Veyron. Comparing it to Windows is like comparing a Timex to a Rolex.

I have been in contact with Mensys (the company that IBM turned OS/2 over to) but they don't have the source code for it and IBM says that the source code has been lost.

Can you blame them? It's not relevant anymore, and its relevance at any time in the past is questionable. I don't have source code to programs I wrote 20 years ago either.

[itsme86]

So basically you want to take a flexible, platform-agnostic system (SQL) and replace it with something that is entirely hardware dependent? Sounds like a pretty big tradeoff. The allure is failing to draw me in.

[Will1]

Perhaps you could explain why you need the segment registers. In modern operating systems, you're given a code segment, a stack, and a data segment. There is no reason to manipulate the segment registers to access these things. If your code requires the manipulation of the CS, SS, DS, ES, FS, etc. registers, then it probably isn't suitable to run on modern operating systems. You should think about converting it to work within the operating systems on which it's likely to run. The memory in protected mode is not segmented in the way that DOS real mode memory was. You don't have a new segment every 16 bytes like real mode and DOS have. On x86 and x64 platforms, in protected mode, segments are logical constructs (in a very similar way to logical tables in an RDBMS) that have a physical (virtual when paging is enabled - on all modern operating systems, it is) base and size. A segment's selector (roughly analogous to real mode segment numbers) is an index in a table that contains segment descriptors, which describe the physical or virtual base address, the size, and a number of other parameters. They bear little to no resemblance to segments in DOS or real mode. Sequential descriptors in the GDT/LDT (global and local descriptor tables, respectively) need not represent adjacent memory regions, for example. They can represent any arbitrary region in memory.

When I originally wrote ADAM back in the early 1980s I didn't just come up with the idea of how to make a file work. It took many yaears starting in 1969 on an IBM mainframe to devise a method of storing and retrieving data. When IBM came out with the PCXT, I thought "WOW I could use that!" I bought one with MASM and programmed the original DOS PC version of ADAM. The DS and ES registers equate to "Base" registers in the mainframe. I used them to pass data back and forth between ADAM and the program that uses (calls) it. MicroSoft and Novell were the two major PC companies of that time and I couldn't get either one to even look at ADAM. It looks like ADAM will go the way of OS/2 because I get nothing but sneers from modern programmers. I guess it is easier to snicker when someone offers a new way of doing things rather than actually try it. I had hoped that I would get a little more open mindedness on this board than I did on the MASM32 board but I guess not.

[Will1]

So basically you want to take a flexible, platform-agnostic system (SQL) and replace it with something that is entirely hardware dependent? Sounds like a pretty big tradeoff. The allure is failing to draw me in.

Not exactly! What I would like to do is replace the code in SQL that accesses the data device with ADAM. ADAM works on your hard drive or a flash drive or whatever.

[Will1]

You haven't been here long enough or developed a sufficient reputation to refer to me in such a casual way, especially since I can tell from the tone of your post that you meant it in a more-or-less derogatory way. Please refrain from doing this.

Not derogatory, sarcastic! I gather from you posts that you are so absolutely convinced that modern Operating Systems are superior to any facet of older Operating Systems such as DOS that pointing out a facet where DOS is superior to modern Operating Systems went right over your head.

[Elkvis]

Not exactly! What I would like to do is replace the code in SQL that accesses the data device with ADAM. ADAM works on your hard drive or a flash drive or whatever.

One path that might suit your intentions might be to use ADAM to implement a storage engine for MySQL. MySQL is an open source RDBMS that has a pluggable storage engine interface. It comes with several by default - MyISAM, InnoDb, Blackhole, Memory, and CSV are just a few. Like I said previously, ADAM's niche would likely be as a backing store for RDBMS tables. If you can figure out how to have more than one file open per process (I can guarantee that it can be done), it might just fit right in with MySQL. The only obstacle I really see is that it's written in assembly language. That tends to be a bit off-putting to most developers. Like I mentioned in an earlier post, modern C and C++ compilers generate outstanding machine code, making assembly language programming unnecessary in most situations, so most developers never learn it. Unless you can find someone who is willing to take over the project and run with it, you'll have a hard time even getting into the game.