Hi all!
This is the hivesys.inf PCNet section. I copied fetnd5a.sys to pcnet.sys.
I can query network properties w/o a crash! All I get is IPHLPAPI.dll need
more work and GetAdapterInfo did not return the expected data.
Bus 0, device 18, function 0, Ven 1106/Dev 3065/class 0200.
Start->Settings->Settings Menu->Network Properties
Select VT6102->Properties, get the VIA PCNet Status Menu, select Properties,
get the VIA PCNet Pro~ Menu, select Internet Protocol (TCP/IP), select
Properties, get the Error menu.
Wow! Did not crash!
Need to check if I'm on the right track here!
Thanks,
James
; ReactOS PCNet NIC driver
; To use the AMD supplied driver change the driver name to pcntn5m.sys
;
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","ErrorControl",0x00010001,0x00000000
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Group",0x00000000,"NDIS"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","ImagePath",0x00020000,"system32\drivers\pcnet.sys"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Start",0x00010001,0x00000003
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet","Type",0x00010001,0x00000001
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","0",0x00000000,"PCI\VEN_1106&DEV_3065\0000"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","Count",0x00010001,0x00000001
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet\Enum","NextInstance",0x00010001,0x00000001
HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Service",0x00000000,"PCNet"
HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Class",0x00000000,"Net"
HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","ClassGUID",0x00000000,"{4D36E972-E325-11CE-BFC1-08002BE10318}"
HKLM,"SYSTEM\CurrentControlSet\Enum\PCI\VEN_1106&DEV_3065&SUBSYS_01021106&REV_10\0000","Driver",0x00000000,"{4D36E972-E325-11CE-BFC1-08002BE10318}\0000"
; Configuration Entries for the PCNet Adapter
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","Characteristics",0x00010001,0x00000000
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","DriverDesc",0x00000000,"VT6102"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ProviderName",0x00000000,"VIA
Tech"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","NetCfgInstanceId",0x00000000,"{RANDOMCFGGUIDFOR_PCNET1}"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","Export",0x00000000,"\Device\PCNet1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","RootDevice",0x00000000,"PCNet1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\Linkage","UpperBind",0x00000000,"Tcpip"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUS_TO_SCAN",0x00000000,"ALL"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUSTIMER",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BUSTYPE",0x00000000,"5"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EXTPHY",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","FDUP",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED0",0x00000000,"10000"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED1",0x00000000,"10000"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED2",0x00000000,"10000"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","LED3",0x00000000,"10000"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","MPMODE",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TP",0x00000000,"1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","AdapterCFID",0x00000000,"811929862"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","AdapterType",0x00000000,"5"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","SlotNumber",0x00000000,"8"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BusNumber",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","FunctionNumber",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EarlyReceive",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","EarlyTransmit",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","BurstLength",0x00000000,"1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveBurstIndicate",0x00000000,"64"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveBuffers",0x00000000,"64"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TransmitBuffers",0x00000000,"32"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ReceiveThreshold",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","TransmitThreshold",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","MapRegisters",0x00000000,"32"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ConnectionType",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","ValidatePacketLen",0x00000000,"1"
HKLM,"SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000","IPXSPXAutoFrame",0x00000000,"0"
HKLM,"SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{RANDOMCFGGUIDFOR_PCNET1}",,0x00000000,"Network
Adapters"
HKLM,"SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{RANDOMCFGGUIDFOR_PCNET1}\Connection","Name",0x00000000,"VIA
PCNet"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","DefaultGateway",0x00010000,"10.65.145.1"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","IPAddress",0x00010000,"10.65.145.79"
HKLM,"SYSTEM\CurrentControlSet\Services\PCNet1\Parameters\Tcpip","SubnetMask",0x00010000,"255.255.255.0"
Hello,
the main XML build file "ReactOS.xml" is referencing a DTD file
"tools/rbuild/project.dtd". But it's not included in the SVN
repository. Is there already such a file? And in that case - could you
please check it in?
Thanks,
Martin
Hi. I'm implementing an EventLog service now. I want to make it 100%
compatible with windows. Windows machines will be able to access reactos
eventlog via rpc.
Undocumented rpc interface is almost reversed now. You can find it in
attached archive with some tests. Ansi functions work very well, but
I have some problems with unicode ones. When I pass initialized with
nulls UNICODE_STRING to a function, it works. When I initialize
structure with some other values, exception is raised on server side
(1783 Stub received bad data). I don't know why this happens. Advapi32
initializes structures with RtlInitUnicodeString, nothing special. Any
ideas?
And I don't know how to compile this with widl and gcc. SEH is not
implemented in gcc, right? How rpc exceptions are handled in ROS? Widl
returns strange errors. Somebody familiar with widl please help me =)
I summarize below the networking status for nic rtl8139 in real hardware
, with the help of Alex , Filip and Hpoussin
- Ping ok with svn 15400
- ping Nok with SVN15402+15404 and >
- ping ok with head (svn 16894) + patch 15402/15404 removed
The interesting part is this:
1) svn 15400
(ndis/io.c:824)(NdisMRegisterInterrupt) Called. InterruptVector (0xA)
InterruptLevel (0xA) SharedInterrupt (1) InterruptMode (0x0)
(ndis/io.c:843)(NdisMRegisterInterrupt) Connecting to interrupt vector
(0x4A) Affinity (0xFFFFFFFF).
(ndis/io.c:848)(NdisMRegisterInterrupt) Leaving. Status (0x0).
2) svn 15402/15404
(ndis/io.c:824)(NdisMRegisterInterrupt) Called. InterruptVector (0x0)
InterruptLevel (0x0) SharedInterrupt (1) InterruptMode (0x0)
(ndis/io.c:843)(NdisMRegisterInterrupt) Connecting to interrupt vector
(0x40) Affinity (0xFFFFFFFF).
(ndis/io.c:848)(NdisMRegisterInterrupt) Leaving. Status (0x0).
3) Svn 16860
(ndis\ndis\io.c:824)(NdisMRegisterInterrupt) Called. InterruptVector
(0x9) InterruptLevel (0x9) SharedInterrupt (1) InterruptMode (0x0)
(ndis\ndis\io.c:843)(NdisMRegisterInterrupt) Connecting to interrupt
vector (0x49) Affinity (0xFFFFFFFF).
(ndis\ndis\io.c:848)(NdisMRegisterInterrupt) Leaving. Status (0x0).
Regards
Gerard
You used the BIOS USB to PS/2 bridge, not a USB driver.
Yours sincerely,
Jaix Bly
----Ursprungligt meddelande-----
From: TwoTailedFox twotailedfox(a)gmail.com
Date: Sat, 30 Jul 2005 17:52:59 +0200
To: Andrew Murphy andrewm1986(a)gmail.com
Subject: Re: [ros-dev] USB mouse support
> Oddly enough, I used 0.2.6 with a USB Mouse on my P4 System. The
> cursor did appear, but the mouse sensitivity was way off. I could
> roughly get it where I wanted to by moving very, very slowly, but this
> wasn't practical, so I switched back to my USB-to-PS/2 way of using
> the mouse.
>
> Good to hear it's near to being useable.
>
> On 7/30/05, Andrew Murphy <andrewm1986(a)gmail.com> wrote:
> >
> >
> > On 30/07/05, Jonathan Wilson <jonwil(a)tpgi.com.au> wrote:
> > > Good to hear.
> > >
> > > Working support for my Microsoft Optical Intellimouse Explorer USB Optical
> > > Mouse is one of the 2 things I want before I will try ROS on real hardware
> > > again. (the other is support for my Belikn Wireless Network Card and
> > > software and enough networking support so I can talk to the wireless
> > router
> > > and from there to the internet)
> > >
> > >
> > > _______________________________________________
> > > Ros-dev mailing list
> > > Ros-dev(a)reactos.com
> > > http://reactos.com:8080/mailman/listinfo/ros-dev
> > >
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.com
> > http://reactos.com:8080/mailman/listinfo/ros-dev
> >
> >
>
>
> --
> "I had a handle on life, but then it broke"
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
Are you sure that we should be acquiring the mutex in the open case?
MSDN says:
bInitialOwner
[in] Specifies the initial owner of the mutex object. If this
value is TRUE and the caller created the mutex, the calling thread
obtains ownership of the mutex object. Otherwise, the calling thread
does not obtain ownership of the mutex....
Thanks,
Joseph
hbirr(a)svn.reactos.com wrote:
> If a mutex already exist, open it instead of create.
> Modified: trunk/reactos/lib/kernel32/synch/mutex.c
> Modified: trunk/reactos/lib/kernel32/synch/mutex.c
> --- trunk/reactos/lib/kernel32/synch/mutex.c 2005-07-30 19:00:33
UTC (rev 16900)
> +++ trunk/reactos/lib/kernel32/synch/mutex.c 2005-07-30 19:03:34
UTC (rev 16901)
> @@ -92,10 +92,24 @@
> MUTEX_ALL_ACCESS,
> &ObjectAttributes,
> (BOOLEAN)bInitialOwner);
> + if (Status == STATUS_OBJECT_NAME_COLLISION)
> + {
> + Status = NtOpenMutant(&MutantHandle,
> + MUTEX_ALL_ACCESS,
> + &ObjectAttributes);
> + if (NT_SUCCESS(Status))
> + {
> + if(bInitialOwner)
> + {
> + WaitForSingleObject(MutantHandle, INFINITE);
> + }
> + SetLastError(ERROR_ALREADY_EXISTS);
> + }
> + }
> if (!NT_SUCCESS(Status))
> {
> - SetLastErrorByStatus(Status);
> - return NULL;
> + SetLastErrorByStatus(Status);
> + return NULL;
> }
>
> return MutantHandle;
Hi all,
I think the *module* node needs two more attributes - *subsystem* and
*windows* - because at present module type and module subsystem are
merged in the *type* attribute and its values are a bit confusing to
me; also cui/gui information is hidden into value names.
I don't know the rbuild code and I can't therefore say if it is an easy
task splitting the logic behind the *type* attribute into tree
attributes whitout affecting the whole program logic.
A short rationale follows.
___
Valid values for the *type* attribute should be:
- library (static)
- hal
- driver
- program
- dll
Valid values for the *subsystem* attribute should be:
- none
- native
- windows
- posix
- os2
- vms
(default "windows"; "none" required for type "library"; "native"
required for types "hal", "driver")
Valid values for the *windows* attribute should be:
- no
- yes
(default "no"; "no" required for types "library", "hal", "driver")
___
Examples:
*ntdll.dll*
<module name="ntdll" type="dll" ...>
note that, at present, it is incorrectly described this way
<module name="ntdll" type="dll" subsystem="native" ...>
*ntoskrnl.exe*
<module name="ntoskrnl" type="program" subsystem="native" ...>
*atapi.sys*
<module name="atapi" type="driver" subsystem="native" ...>
--
:Emanuele Aliberti
There are pretty strong indications that the reactos.com box was cracked. It
took part in a DDoS attack. As a consequence, it was isolated from the
network. Unfortunately, I'm on vacation right now so I don't have physical
access to the box and am unable to fix/reinstall.
For the moment, I've moved the mailing lists to a backup box. I am not
moving the website, since it seems the attack was carried out via the
website (a vulnerability in one of the php script packages we use). I'll put
up a dummy page informing visitors.
Not sure how far along the release of 0.2.7 is, but I'd like to suggest to
put it off for at least another week, until I'm back and can sort things
out.
Apologies for the inconvenience, Ge van Geldorp.
Svn 16860 has fixed this problem
(drivers\net\ndis\ndis\io.c:824)(NdisMRegisterInterrupt) Called.
InterruptVector (0x9) InterruptLevel (0x9) SharedInterrupt (1)
InterruptMode (0x0)
(drivers\net\ndis\ndis\io.c:843)(NdisMRegisterInterrupt) Connecting to
interrupt vector (0x49) Affinity (0xFFFFFFFF).
(drivers\net\ndis\ndis\io.c:848)(NdisMRegisterInterrupt) Leaving. Status
(0x0).
I'll test again "ping" command with head
Regards
Gerard
Hello mr. Wilson and all others who is interested in USB mouse & keyboard.
USB mouse and keyboard is being worked on right now, and it will be ready before 0.3.0 and probably after 0.2.7. We are talking weeks not months. Then again, this will be the USB Key and mouse driver, so expect some time for it to mature. Keyboard drivers is probably to be released first because this driver doesn't need HID stack, then the mouse driver will be developed, but there is a need there if some one could find a USB mouse driver C source that doesn't use a HID stack it will be done a lot faster.
One interesting detail is that the development will be tested on XBox hardware which will make the XBox-port usable as a development platform.
Yours sincerely,
Jaix Bly
----Ursprungligt meddelande-----
From: Jonathan Wilson jonwil(a)tpgi.com.au
Date: Sat, 30 Jul 2005 02:21:02 +0200
To: ReactOS Development List ros-dev(a)reactos.com
Subject: [ros-dev] USB mouse support
> How far away is support for USB mice?
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev