Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Radek

Pages: 1 ... 4 5 [6] 7 8 ... 14
76
No success here. Even after picking the file from the directory listing, I am getting "forbidden" plus some japanese text. Okay, let's wait for Hobbes ...

77
This must be a madness of the CONFIG.SYS parser. First of all, it compains that it has PMMERGE in the PROTSHELL statement - and it does not. When you comment out a line from CONFIG.SYS then the parser invents another "error". The parser must be completely wrong with its parsing.

I cannot suggest anything reasonable here  :-\ One more experimenting: the line counter in the error messages seems to count only "valid" lines, not the blank or comment ones. The problematic lines are elsewhere, the code you have posted seems to be okay. Try to delete all blank lines and all comment lines from CONFIG.SYS and see what is now line 130 and line 204. No saving after the experiment, of course. Also, check that you have a blank line at the end of CONFIG.SYS. For some unknown reason, if CONFIG.SYS does not contain this line, you can get troubles during startup.

78
First of all, start maintenance console from your CD and check what is in your CONFIG.SYS. Check what is on lines 130 and 204 (and around them). Post your findings. PMMERGE is a DLL, not an EXE, so that it cannot be a PROTSHELL. The correct value should be:

PROTSHELL=PMSHELL.EXE

If you see PMMERGE.DLL there then change it to PMSHELL.EXE. The PMMERGE must be some terrible misunderstanding.

79
Storage / Re: OS/2 - Linux and JFS
« on: 2009.11.10, 14:46:08 »
Cris, have you tried to put umask = 0 in fstab? I have met a similar problem with a FAT32 partition intended for communicating between eCS and Debian. The partition is mounting as root/root so that I had only read access to it from Debian. A good for nothing communication partition  :-\ Allowing rwx access to anybody in fstab has solved the problem.

I haven't experiented with eCS JFS partitions on my machine, they contain valid data  :)

80
Hardware / Re: A 32 bits device driver model for OS/2
« on: 2009.11.02, 21:38:05 »
Thanks you all for info, especially to Rudi for making the things clear. As I feared, my (not very consistent) knowledge about 32-bit PDDs wasn't too far from reality: some support for IFS and GRADD, incomplete and specialized to particular kinds of drivers. The rest of 32-bit PDDs runs "do it yourself" thunking from 16-bit to 32-bit and back. Oh, well ...

81
Hardware / Re: A 32 bits device driver model for OS/2
« on: 2009.10.29, 23:24:59 »
A nice paper but it only proposes a possible 32-bit DD architecture. It does not state that anything of the proposed architecture is or has been installed. I would like to know how much of 32-bit PDD is now supported by OS/2 ...  :-\

82
It's worse - if the BIOS checks the contents of the diskette then it can be supposed to check the contents of the HD as well ... Therefore, questions are asked:

(1) Is it possible to extract the HD from the ATM?
(2) Is it possible to attach the HD to another comp?
(3) Is it possible to create a backup of the HD partitions? The HD can be encrypted.

I would give up without the backup because I wouldn't want to risk that the ATM has started for the last time just before I meddled with the HD contents. Even with the backup I am running certain risk that I won't be able to restore the contents of the HD when something will go wrong  :-\

As far as the diskette is concerned, I would suppose that the check will not go beyond the root directory. If the diskette is a plain FAT12 then any DOS disk editor would help, for example Norton Disk Doctor from Norton Utilities. The boot sector is Track 0, Sector 0 on the diskette so that a small DOS program making a few int 13h calls should do the trick. As far as the linux machine is concerned, IMO DosBox should allow you physical access to the diskette. You should be able to run ndd.exe on the diskette from DosBox.

83
It must be either the BIOS or the diskette who is guilty. And it can be the security issue. It is possible that your (special) BIOS allows setting it to diskette as a primary boot device but the setting is ignored in the end. It can be the program on the diskette, which - once it gets control - performs a warm reboot from the HD. I can propose the following:

(1) First check whether you can boot from a diskette at all. A lot of bootable floppies and CDs can be found at http://bootdisk.com Download, for example, DOS 5, create a bootable floppy and try. You will need a winblows machine at hand, the boot images are packed as winblows apps.

If you succeed with DOS 5 diskette then you are done. The diskette contains FDISK, which is able to delete any partition in the HD, no matter which FS the partition contains. Ignore senseless partition sizes (DOS 5 is rather diluvial now  ;D ) and go on deleting. The HD gets cleansed correctly even if the partition data will not be recognized okay.

If you can boot from a CD then there is gParted ISO. For example, http://www.icewalkers.com/Linux/Software/526550/GParted-livecd.html It's a linux FDISK, which is able to delete HD partitions as well.

84
Programming / Re: GCC and DosQueryProcAddr
« on: 2009.10.15, 22:22:25 »
Both parameters of my_viogetansi() are USHORTs and you are passing a 32-bit address (&ret) and a 32-bit int to it. Both parameters get truncated to 16-bit and zero extended when passed to my_viogetansi(). This is disastrous for the address and you get a GP fault during my_viogetansi() processing.

Check the assembler code of main(). Possible causes of problems with the call:
(1) my_viogetansi() is 16-bit and it is called as a 32-bit near pointer. GP fault. Needs explicit thunking.
(2) my_viogetansi() expects 2 words on the stack and gets 2 dwords. GP fault. Needs parameter trickery in my_viogetansi().
(3) The paramters get truncated when passed to my_viogetansi(), GP fault caused by the address.
(4) Who is removing the parameters from the stack? Declarators APIENTRY and EXPENTRY are the same as PASCAL. Therefore if the function is APIENTRY then if must remove its parameters from the stack. If the caller, that means, main() should remove the paremeters from the stack, then the funciton must not be APIENTRY.

If you have access to the DLL code then redo my_viogetansi() as

// well defined DLL functions in OS/2 are APIENTRY (or EXPENTRY) in OS/2 :)

void APIENTRY my_viogetansi( ULONG addr, ULONG handle )
{
...
}

and try again :)

At any rate, you should have got a warning from the compiler about truncating procedure params when compiling main(). If you haven't got such warning then throw the compiler down the drain and try another one.

85
Programming / Re: OS/2 queues
« on: 2009.10.09, 09:17:33 »
Stored for possible later references :) Is the DLL UNI or SMP? It's doscall1.

86
Setup & Installation / Re: OS/2 Warp 4 Bootable CD Image?
« on: 2009.10.03, 15:03:44 »
I am sorry, I cannot help efficiently right now. The z:\ refers to the CD you have booted from. Because it is "z:" and not "s:", you are still running in "legacy mode" - before switching on OS/2 CD driver(s).

The prompt seems to be a promt from an "OS/2 window". You should be able to issue any OS/2 command, as if you had opened an OS/2 prompt from an installed system. Naturally, CD is read only so that any kind of writing will fail.

What is the prompt exactly, depends on the nature of the ISO having been sent to you by Ivan. It can be a "maintenance CD" which is not supposed for installing but for solving problems with hanging OS/2. It gives you access to an (installed) operating system and allows you making fixes before you try to boot again. Such CD won't help you. It can be really a bootable installation, which does not understand your computer and which - after the installer having crashed - has ended on a prompt. Ivan could say you more.

W4 CD was not bootable. In fact, the CD contained images of installation floppies and the installer installed the the system from the images. In the other words, nothing else than installation from diskettes, only the installer has been a little patched so that it read the images from the CD instead of wanting diskettes. There is no boot image on the W4 CD, the CD is pure data. The whole things is started from a diskette, which in turn starts the installer on the CD. The installer then does the rest. For example, that's why you need to return to "Diskette 1" after FDISK and Ctrl-Alt-Del.

Making a bootable CD for W4 means making some botable CD and passing the boot loader the contents of the first two installation diskettes along with the data from the CD and (maybe) a bit patched installation script. A bootable CD for W4 is an artifact, not a "natural thing". I've never needed it because I had floppies in my "W4 times".

87
Setup & Installation / Re: OS/2 Warp 4 Bootable CD Image?
« on: 2009.10.03, 09:55:03 »
I see. Well, I've never installed W4 without having floppies so that I do not have experience with making a bootable installation CD for it. But, perhaps, someone around can be more experienced. The task is: Make a bootable ISO, which can be used for installing W4 from scratch - not a maintenance CD but an installation CD.

In the meantime, you can use a more complicated way for smuggling W4 on your machine. You will need:

(1) Another comp, where you can install W4 temporarily.
(2) Download PING from http://ping.windowsdream.com/ PING is a Linux partition backup/restore which knows HPFS so that you will be able to port an image of a W4 installation from "another comp" to your machine. One of the PING files is a bootable ISO of PING. PING is a freeware. Prepare a CD.
(3) Download DFsee from http://www.dfsee.com/ DFsee is a HD editor, FDISK, etc. DFsee is paid but it has an enough long free evaluation period. Download DFsee bootable ISO, do not burn right now :) wait until you'll be ready.
(4) Have a transport media (USB stick, CD, 250 MB Zip, etc.) which can hold ca 230 MB data ready.

(5) Install "bare bones of W4" on the "another comp". Do not install anything that you can install later from the installed system. Install with generic VGA, patch HD driver with Daniela's one.
(6) Boot from PING CD and backup the partition. The backup will be ca 230 MB, PING stores only used sectors and bzips them.
(7) Make a partition on your comp without floppies using DFsee. The partition should be of the same size as the partition where you have installed W4.
(8) Boot your comp with PING CD and copy the partition with W4 to your comp.
(9) Boot your comp with DFsee and "accomodate" the copied partition on your HD. Note that "another comp" had anoher HD with another sectors/track, etc.
(10) Boot from your HD. W4 should start. Finish the installation.
(11) PING once more: backup the final installation from your comp and save the image for later use. You can study PING deeper now :) It allows you, among others, to create a bootable ISO which will contain the partition image and which will install it after booting. The ISO can also create the partition when needed. I have no experience with it but it should be possible.

Uffff ... A bit complicated but it works. I have installed eCS this way until eCS was able to boot from a USB CD. I wasn't able to install, either, and this was the only way of installing.

88
Setup & Installation / Re: OS/2 Warp 4 Bootable CD Image?
« on: 2009.10.02, 20:34:52 »
The z:\ is okay, it's your CD where you have booted from. Your HD is c:\, d:\ and so in.
Please, be more specific. What do you need to do? Do you have OS/2 installed on your HD and do you need to solve problems with it? Do you need to install from a CD because you have a machine without floppies?

89
Thomas is right, it happens, but when it happens:

(1) Certain old IBM "suites".
(2) Most of apps ported from winblows, which use "Innotek runtime". They are still winblows apps, the runtime pretends to them that they are still running under winblows. And they still behave like winblows apps. They install to "c:\Program Files" - e-h-h - I wanted to say, to c:\programs, and they use "registration database" for storing their configurations.
(3) Certain Unix ports.
(4) Badly written packages with badly written installation scripts.
(5) Badly written apps with hardcoded "c:\programs" and similar places.

Well, we cannot avoid apps (1) - (5) completely  :-\

Well written apps allow you to install them where you need them. There are only few "standard places" in OS/2 - root, \os2, \boot and some others. These dirs contain system data and the system will search its data there and (often) nowhere else.

90
I recommend creating 2 partitions for your eCS.

(1) The "system" one, which will contain only operating system related data and apps. You will install eCS here. Later on, you will put anything here only if it is a "system-wide thing". This partition can be relatively small. 2 GB is more than enough. Make this partition HPFS - it's too small for JFS giving you any considerable benefits and moreover, HPFS is a long time used (therefore, long time tested :) ) file system written by IBM.
(2) The "data" one, which will contain everything else. You will keep your data and apps here. Note that eCS is not winblows so that if you command "install on D:\mydir", the app will install on D:\mydir and not on C:\winblows. Give the partition the rest of your disk (or the rest of space reserved to eCS). Make this partition JFS - HPFS is painfully inefficient on large partitions and moreover, it has the 64 GB limitation.

Therefore:

(a) During install, select "Custom" installation.
(b) Create 2GB partition - this will be your system. Make it "installable" and "startable" because you will install here.
(c) Create the data partition. Save changes and quit FDISK.
(d) Format the 2 GB partition as HPFS. You can even afford the luxury of having the partition checked on errors. It's small so that it will not take a long time.
(e) Install.
(f) Format the data partition from your installed system as JFS.

Pages: 1 ... 4 5 [6] 7 8 ... 14