P6T Deluxe Driver install

[imk]

Hello,
ASUS P6T Deluxe MB, 3Gb RAM, 5570 Xeon CPU.
So just down loaded ReactOS 3.16 and got it to install and boots ok after trying four mice and two keyboards.
(Had to turn ACHI off and IDE on)
Am now trying to install some drivers but they won't install.
Tried from the ASUS CD, but it says incompatible OS.
So download the Ethernet Yukon driver for NT and put it on floppy but system does not look at floppy when I try manual install.
I guess I am really missing something here can you help please?
IMK
PS What I have seen so far looks really great and if I get it to work for me i'll subscribe and bin plans for nasty Windows 8

[milon]

Hi imk, welcome to the forum!

Please consider posting your setup at https://www.reactos.org/wiki/PC_ROS_Rigs. That's where we track what (combination of) hardware works and what doesn't work.

Anyway, I'm not sure what to suggest to help you with your setup, but I'm sure someone here can help you.

[imk]

Hello,
I would like to be come a tester for ReactOS how do I go about it please?
imk

[Black_Fox]

It's easy - you download the newest trunk build (also known as daily build) from https://reactos.org/getbuilds and then you can test the newest ReactOS build available.

[Webunny]

Hello,
I would like to be come a tester for ReactOS how do I go about it please?
imk

First you have to decide whether you are going to test it on hardware (HW), or on a virtual machine (VM). You can do both, of course, but the two are quite different in their handling.

See also the wiki: https://www.reactos.org/wiki/Debugging# ... ng_methods

I've done both, in particular with Virtualbox and Putty (https://www.reactos.org/wiki/VirtualBox ... bug_output), but since then I shifted more to almost exclusively hardwaretesting (https://www.reactos.org/wiki/PC_ROS_Rigs).

Both are fruitful. For repeated testing, a VM is much more convenient. However, I find that ultimately, it's HW testing that really counts and shows if it's *really* working. HW testing is more die-hard and is less suited for repeated mass-testing (this is mostly related to the drivers). It's also a fairly small niche; not many do this, either because they're not able (no HW where ROS works on) or just because it's generally more difficult. It also means any new HW tester is highly welcomed.

Of course, as said, you can go for both options.

[imk]

webunny,
many thanks for the reply. HW tester will be fine by me as I ultimately never want to be in a position where I have to move to Windows 8 or the like. So I need an alternative for all my Win32 apps, hence by the time Win7 is over I hope ReactOS will be ready.
I have at least one dedicated machine I can test on and could probably find two or three more. (Ranging from pent iii to i7)

My background is IT, been in it for forty years so done a bit of testing in my time.
Am retired now but am still developing my own apps on Win32 and embedded micro-controllers (robotics)
So I have a good background in C and some C++ so maybe able to do some project coding in the future.
But this will have to be some months away as up to my eyes in other projects.
ian

[middings]

I would like to be come a tester for ReactOS how do I go about it please?

The Testing Introduction page may also be useful. However, it was last edited in 2012 and still refers to BugZilla as the ReactOS Project's bug tracking software. The ReactOS Project now uses JIRA. (Links to ReactOS BugZilla pages no longer work.)

[Webunny]

webunny,
many thanks for the reply. HW tester will be fine by me as I ultimately never want to be in a position where I have to move to Windows 8 or the like. So I need an alternative for all my Win32 apps, hence by the time Win7 is over I hope ReactOS will be ready.
I have at least one dedicated machine I can test on and could probably find two or three more. (Ranging from pent iii to i7)

My background is IT, been in it for forty years so done a bit of testing in my time.
Am retired now but am still developing my own apps on Win32 and embedded micro-controllers (robotics)
So I have a good background in C and some C++ so maybe able to do some project coding in the future.
But this will have to be some months away as up to my eyes in other projects.
ian

Generally speaking, I think it's best if you start off with the oldest PC's (with a classical bios). And viewing the testpage, it's more likely to work on a desktop than on a laptop (though granted, statistical analyses of that is difficult, with so few examples). Note that there aren't any certitudes, though. Of the 4 rigs I tried, only one worked with ROS. (viewtopic.php?f=2&t=12924). And unless you want to go through rigorous and tiring regression testing, like I did that time - and believe me, you don't - it might be a good idea if you bought or found a serial modem cable too, for debugging purposes.

Glad to hear you know C and C++. I'm in the IT too, but I'm no coder. I'm sure someone who can code in C and C++ will be highly valued. Mind you that they have some stringent - I have to be careful when using that word :-p - conditions if you really want to help with the code itself.

Disclaimer; I'm NOT talking about filing bugs on JIRA, and I guess I won't link to the job-page neither, or - gasp - it could be I frighten people away. (oh noes!).

Sorry, ian, was an inside thing, don't break your head over it.

Anyway, welcome, and be sure to let us know your experiences with your HW testing. As said, there are only a limited amount of testers that focus on RH testing, so all new RH testing is highly appreciated.

[justincase]

Hello imk, unfortunately Windows driver support is still quite hit & miss, so I'm not very surprised when any piece of hardware doesn't work (unless it worked before, in which case ... regtesting it is), however if you can get debug logs from the affected ReactOS install (see this Wiki Page) it'd be a good idea to make a bug report (including logs) on the bugtracker (actually it'd be a good idea anyway, but get debug logs if you can, it helps).

@webunny: When people had issue with you mentioning "stringent" conditions, I'm pretty sure the what they were taking issue with was really that, anyone can get as close to the code as they want in their own working copy, and patches posted in the bugtracker are indeed appreciated from just about anyone. (¿"open-source" anyone?)

Glad to hear you know C and C++. I'm in the IT too, but I'm no coder. I'm sure someone who can code in C and C++ will be highly valued. Mind you that they have some stringent - I have to be careful when using that word :-p - conditions if you really want to help with the code itself.

Disclaimer; I'm NOT talking about filing bugs on JIRA, and I guess I won't link to the job-page neither, or - gasp - it could be I frighten people away. (oh noes!).

Regarding the "stringent conditions", (correct me if I'm wrong, but) I'm fairly certain those are only for people who want to directly commit to the ReactOS repository (svn/FishEye), while (as far as I know) the only conditions for submitting patches are that you've never seen Microsoft's source code, and that if you're patch uses code from some other project commiting your patch won't introduce licensing issues.
If you're capable of it I'm sure the ReactOS devs would love to have you get as close to the code (in your own working copy) as you need to to help fix and/or implement whatever is broken or missing so far, and submit your testing results, test applications, and patches via bug reports on the bugtracker (currently JIRA).

Happy Testing/Coding.

[EmuandCo]

Our driver wizard is not really good working yet. You need to play around a bit by copying the inf files to C.\ReactOS\inf, dlls to C:\ReactOS\system32 and sys files to C:\ReactOS\system32\drivers. Then it should install it and maybe even work ^^

[Webunny]

Hello imk, unfortunately Windows driver support is still quite hit & miss, so I'm not very surprised when any piece of hardware doesn't work (unless it worked before, in which case ... regtesting it is), however if you can get debug logs from the affected ReactOS install (see this Wiki Page) it'd be a good idea to make a bug report (including logs) on the bugtracker (actually it'd be a good idea anyway, but get debug logs if you can, it helps).

@webunny: When people had issue with you mentioning "stringent" conditions, I'm pretty sure the what they were taking issue with was really that, anyone can get as close to the code as they want in their own working copy, and patches posted in the bugtracker are indeed appreciated from just about anyone. (¿"open-source" anyone?)

Glad to hear you know C and C++. I'm in the IT too, but I'm no coder. I'm sure someone who can code in C and C++ will be highly valued. Mind you that they have some stringent - I have to be careful when using that word :-p - conditions if you really want to help with the code itself.

Disclaimer; I'm NOT talking about filing bugs on JIRA, and I guess I won't link to the job-page neither, or - gasp - it could be I frighten people away. (oh noes!).

Regarding the "stringent conditions", (correct me if I'm wrong, but) I'm fairly certain those are only for people who want to directly commit to the ReactOS repository (svn/FishEye), while (as far as I know) the only conditions for submitting patches are that you've never seen Microsoft's source code, and that if you're patch uses code from some other project commiting your patch won't introduce licensing issues.
If you're capable of it I'm sure the ReactOS devs would love to have you get as close to the code (in your own working copy) as you need to to help fix and/or implement whatever is broken or missing so far, and submit your testing results, test applications, and patches via bug reports on the bugtracker (currently JIRA).

Happy Testing/Coding.

Exactly. It has nothing to do with filing bugs or patches through JIRA, and it never had. The stringent conditions ARE mentioned on the jobpage, btw, and also what the job is about. But still it was deemed too confusing, apparently. If I hadn't explicitly said this again in my post that I'm talking about direct coding and not about JIRA, I'm sure I would get complaints again. We're talking about software engineers and people who can code in C and C++; I think directly coding isn't beyond their immediate possibility, contrary to the casual non-coding user. If you aren't pointing that possibility to them - including the conditions - to whome are you going to show it? We have a jobpage and we're afraid to show it even to people who could qualify. I still think this attittude is baffling, but whatever.

Anyway, as far as real HW testing goes, the more, the better. I note that some haven't tried the any new builds in months, though, so here's an appeal to all HW testers to try out another build on their machines (especially those who failed to get it working with other builds). I'm thinking of, ultimately, making a visual representation (much like the one on IGG), where the progress of ROS working on rigs over time (with the progression of builds) is plotted and shown. For that, the more input (number of builds), the better. A 100 or so in total would be the minimum.

[justincase]

Wow webunny, you really take things in subjective context.
The point of (that portion of) my post wasn't to side with anyone, or to get this thread off-topic, but to make a small aside to you that your choice of words was the main issue in the other thread. ("won't let you get close to the code" is really quite a strong statement, this is what might scare people off)
By all means post a link to the Jobs page (it wouldn't be up on the website if it wasn't to be seen), just don't make it sound like "if you don't fit these qualifications we don't want you touching our code, you can't help us, goodbye" (which was how it came across to several people in the other thread).
Posts linking to the Jobs page should be less off-putting, perhaps something along the lines of:


Ian (imk), I'm glad to hear you're interested in helping the ReactOS project, and also that you have some experience with C/C++ programming, please do all testing with trunk builds (found at http://www.ReactOS.org/getbuilds) as "Release" versions are out of sync with current development, and feel free to to report any bugs you find on our bugtracker (please search first though, duplicates can confuse things), and if you feel you can help with the code itself please visit the Wiki and/or Development sections of the website for help Getting the Build Environment (w) and Source (w/d), Compiling (w/d), and Submitting Patches (w), if you have any questions please use the forums (which you've obviously already found ), and once you're familiar & comfortable with all of this, do you perhaps qualify for a paid contract? (see "Jobs" page for info)

Also please don't let the occasional forum squabbles scare you away, I'm convinced that just about everyone who posts here means well for the project, even if we occasionally don't sound like it.

And to finally return to the threads original topic:

So download the Ethernet Yukon driver for NT and put it on floppy but system does not look at floppy when I try manual install.

Floppy support is a bit buggy too, I recommend you check the bugtracker to see if your issue has been reported yet.
Also for file transfer, see if a USB Flash Drive works for you (it's a work in progress, but apparently it works just fine for on some people's hardware).
[... one more edit : ReactOS is currently targeting the Windows server 2003 version of NT (5.2), so you'll need a newer driver than would work for WinNT 3.x/4.x]

[imk]

Yes I am happy to help where I can, as for C/C++ coding that will have to be later in year before I apply as too busy on other projects at this time.
Thanks for the heads up re testing latest builds and have downloaded bootcd-62898-dbgwin.7z, but how do I unpack it to an installable iso please?
Ian

[justincase]

With the greatest archiver of all time : 7-zip

[Black_Fox]

WinRAR also supports extracting of 7z archives, if you're on Windows.