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 - Lars

Pages: [1] 2 3 ... 99
1
Thank you very much for your offer but that won`t be necessary.
Glad you got it working. Which means I can now update the existing package with the updated .NIF file.
By the way, could you attach your protocol.ini, just out of curiosity ?

3
The best I can think of is to look into "Presentation Manager Driver" source code and see how it is being used. Other than that, I would not know.

4
What happens if you maximize and then restore a window while in seamless mode ?

Another idea: open Windows in full screen mode, go to ProgramManager->ControlPanel->Desktop and set "Border Width" to say 3. Maybe you need to change back and forth between two values. The default value seems to be 3. Note that this will not be possible if you are in seamless mode !

If that still does not help: there are entries in OS2.INI like "WIN_RES_x". In each of these there are 4 keys that reference what windows display driver is in use for fullscreen and seamless, respectively. Maybe you will have to manually update each of these to match your settings in system.ini.

5
I don't pretend to understand it but just a gut feeling: have you tried and toogle between different OS/2 Desktop schemes ? Maybe that helps.
If there is something like Window Desktop schemes (I cannot remember) you can try that, too.

Are you using the default drivers (that come with GRADD, I think) for fullscreen and seamless Windows or have you replaced these with the Windows drivers that Martin is advertising:
https://www.os2world.com/forum/index.php/topic,3836.msg49420/topicseen.html#new

?

6
How to use this .NIF file:

1) get the latest driver for your Xircom CE2 card: https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/new/Xircom_CreditCardIIps_2-04.zip

2) unzip the file into a temporary directory

3) change to the "NDIS" subdirectory of that temporary directory and copy/overwrite the CE2OS2.NIF file to that directory

4) run the "Network Adapters and Protocols" tool to install the driver by browsing to the "NDIS" subdirectory

A word of wisdom: The CE2NDIS.OS2 driver seems to support quite a few settings that I now added to the CE2OS2.NIF file so that they can be set and written to PROTOCOL.INI. Amongst those settings there are a couple of boolean settings with "Yes"/"No" keyword values for true/false. I think the Xircom device driver writers took a shortcut for boolean values in that they are only looking for the keyword instead of the proper keyword value. That said, it means that if you want to delete a boolean setting you will actually need to wipe the keyword value to an empty string instead of setting it to "No" so that it will be completely removed from PROTOCOL.INI. Additionally, it might be possible that for boolean settings, the driver will only expect to see the keyword instead of the keyword = value line. It might therefore need some experimentation.
Most importantly, the CE2NDIS.OS2 driver also supports point enabled operation by setting CARDSERVICES and SOCKETSERVICES both to "No". So you can still install PCMCIA card and socket services support and then ignore the slot where you inserted the Xircom card as suggested by Steve.

Another word of warning: per default the driver operates in "memory" mode and not "io" mode where memory means the drivers registers are memory mapped (addressable by a normal memory address instead of an io port). The address range accepted by the driver/the default address (expressed as a real mode segment value) might not be available on your system. If you have odd system behaviour, you might then try other values for the [MEM] keyword. The ArcaOS memory utility (or the QSINIT loader) can help you with the display of reserved memory regions on your system. I can help if that should become relevant/necessary.

Once you find out that the .NIF file works for you, let me know and I will rebundle the driver zip with this updated .NIF file and reupload to Hobbes.

7
Sorry for the late reply, had some hardware issues on the Thinkpad. The original drive died so I replaced with a flash card. The Xircom dongle also seems to be defective. I installed on a Windows 98 laptop and got the drivers installed but was getting inconsistent pings at the slightest touch of the dongle.

@Martin - I downloaded the drivers you posted, need to get a dongle to test. Thank you.

In case you want to retry your CE2 card with the driver set that Martin provided (say "FIN-XIR2.ZIP"):
the .NIF installation file would need a "brush up" to actually install the proper entries into the PROTOCOL.INI file.
Gleaning at the driver binary (CE2NDIS.OS2) and other .NIF files from Xircom, I think I would be able to provide you with a fixed .NIF file.

I can also see that even with the CE2NDIS.OS2 driver (and a corrected .NIF file), you will be able to ignore socket services and run the driver in "point enabled" mode which would allow you to always have PCMCIA support installed. If set up correctly via PROTOCOL.INI, the driver will just ignore/bypass the card services.

@Martin: would you see any issues in uploading these drivers to Hobbesarchive ? I am not the legal expert ...

If you would be willing to cleanup the .NIF file for install I would be more than happy to test and buy a cup coffee or make a donation for the work put in. I have a dongle on the way and should be here next week.

8
Sorry for the late reply, had some hardware issues on the Thinkpad. The original drive died so I replaced with a flash card. The Xircom dongle also seems to be defective. I installed on a Windows 98 laptop and got the drivers installed but was getting inconsistent pings at the slightest touch of the dongle.

@Martin - I downloaded the drivers you posted, need to get a dongle to test. Thank you.

In case you want to retry your CE2 card with the driver set that Martin provided (say "FIN-XIR2.ZIP"):
the .NIF installation file would need a "brush up" to actually install the proper entries into the PROTOCOL.INI file.
Gleaning at the driver binary (CE2NDIS.OS2) and other .NIF files from Xircom, I think I would be able to provide you with a fixed .NIF file.

I can also see that even with the CE2NDIS.OS2 driver (and a corrected .NIF file), you will be able to ignore socket services and run the driver in "point enabled" mode which would allow you to always have PCMCIA support installed. If set up correctly via PROTOCOL.INI, the driver will just ignore/bypass the card services.

@Martin: would you see any issues in uploading these drivers to Hobbesarchive ? I am not the legal expert ...

9
Marc, you are saying that you are using XIRCOM card CE2 but you have installed driver CE3NDIS.OS2.

Are you sure that is the correct driver for your card ? On the other hand, I cannot find anywhere a driver CE2NDIS.OS2.

Anyway, the driver that Steve has suggested (the point enabled driver) is here:
https://archive.org/download/Xircom/Xircom.zip

10
Can you post your setup.cmd and also protocol.ini ?

The error does not sound as if this is HW or driver related. It rather sounds like TCP/IP not being set up correctly.

By the way: you might also consider applying the patch to the NDIS driver:
https://www.os2site.com/sw/drivers/network/3com/3c589patch.zip

That might not strictly be necessary on your system but it surely won't hurt either. In addition, it will make the "3net_log.exe" utility work.

Finally, look here, it is about Warp 4 but since you are using Warp 3, it might apply nonetheless:
https://www.os2world.com/olderforum/OS2World%20Ultraboard/www.os2world.com/cgi-bin/ultraboard/UltraBoardea6e.html?action=Print&BID=62&TID=1518&SID=

11
Programming / Re: native mainframe mini-clone
« on: October 17, 2025, 11:00:34 am »
I think Rich said it all and I am quoting the Intel Spec (where Intel Term "IA-32e mode" =  "AMD64 compatiblity mode"):

Chapter 6.2.1 "Code-Segment Descriptor in 64-bit Mode"

IA-32e mode uses a previously unused bit in the CS descriptor. Bit 53 is defined as the 64-bit (L) flag and is
used to select between 64-bit mode and compatibility mode when IA-32e mode is active (IA32_EFER.LMA = 1).
See Figure 6-2.
— If CS.L = 0 and IA-32e mode is active, the processor is running in compatibility mode. In this case, CS.D
selects the default size for data and addresses. If CS.D = 0, the default data and address size is 16 bits. If
CS.D = 1, the default data and address size is 32 bits.
— If CS.L = 1 and IA-32e mode is active, the only valid setting is CS.D = 0. This setting indicates a default
operand size of 32 bits and a default address size of 64 bits. The CS.L = 1 and CS.D = 1 bit combination is
reserved for future use and a #GP fault will be generated on an attempt to use a code segment with these
bits set in IA-32e mode.

That said, the Processor will only recognize the "CS.L" flag and treat it as such when it has already been placed into the "IA-32e mode".
Only then will "CS.L" make the difference (CS.L = 0 -> CS.D selects between 16-bit or 32-bit as the default data/address size, CS.L = 1 -> CS.D is ignored and even expected to be 0 and default data size of 32-bit and default address size is 64-bit)

As far as I understand, if you run the Processor in IA-32e mode you will have a code segment descriptor with "CS.L = 1" (in the global descriptor table). This descriptor is used for 64-bit protected mode programs by loading it into CS, it will never change, implicitely cover all of the address range and effectively disables segment protection (which is never used in IA-32e "native" mode).

In order to run 32-bit or 16-bit protected mode programs, you will add additional code segment descriptor with "CS.L = 0" (in the global descriptor table) which when CS is loaded with this segment selector will allow the distinction between 16-bit and 32-bit default data/address size with the Processor looking at the "CS.D" bit.

You should be able to verify this under "64-bit" Windows: if you run a 64-bit program under a debugger, it should have a different CS selector then if you run a 32-bit program under that debugger.

12
Programming / Re: native mainframe mini-clone
« on: September 22, 2025, 05:32:21 pm »
Correction: it is sysenter/sysexit that is used and not syscall/sysret.

For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.

For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)

Hi Lars.

I'm not sure if you've used the wrong terminology or I'm just confused.

x32 is a target of gcc. I'm not very familiar with it, but I believe it uses x64 instructions, but 32-bit addresses. And it does the latter (as I just found out) by using 0x67 override (which isn't appropriate if you were really running in x86 mode).

So this is very different from x86, and that's why the different target exists. ie it isn't i386.

What you described above sounds like you are describing x86 (aka i386 aka 80386).

Correct. The system stays in "protected 32-bit" mode, aka x86. It does not change to long mode.

13
Programming / Re: native mainframe mini-clone
« on: September 15, 2025, 09:43:01 am »
Correction: it is sysenter/sysexit that is used and not syscall/sysret.

For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.

For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)

14
Programming / Re: native mainframe mini-clone
« on: September 14, 2025, 11:25:10 am »
You might want to have a look at:

https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/system/drivers/misc/SysCall_3-0.wpi

That is a package that I have written to run code in Ring 0.
It comes with full source code. Which would allow you to adapt/extend it to your needs.

The idea was to have an interfacing DLL to be used by an application. That DLL will return to the caller an entry point that will allow the caller to execute user functions in Ring 0.

It uses the syscall/sysret instructions as the fastest way to enter Ring 0.

15
Setup & Installation / Re: Extremely slow Warp 4.52 installation.
« on: September 05, 2025, 01:58:01 pm »
Have you checked that (memory) caching is enabled in BIOS?
I seem to remember for old PCs that this could be turned off and on.

In general I would have a look at what the BIOS offers. There also sometimes existed something like a switch "OS Select For DRAM > 64MB" which you might need to turn OFF (weird, ain't it?).

If you have something like "cache BIOS" or "BIOS shadowing" then turn that OFF.  OS/2 does not make much use of the BIOS. Your system memory (and also memory cache) is better used for other things.

Pages: [1] 2 3 ... 99