Page 2 of 4

Posted: Fri Nov 24, 2006 7:45 pm
by Z98
It was in the same thread the devs talked about why they preferred C over C++. Generally, anything that's not part of NT, they're not likely to ship with the distro. An implementation .NET framework is one of the few exceptions since it's a Microsoft technology that's becoming more and more part of the operating system. DirectX is another example that they want to implement. Everything else, from a different shell to libraries like GTK and Qt they won't include because they know they can leave it to the end user to get if they really wanted it. And to be blunt, it's not like the core of ReactOS needs GTK or Qt. The developers will only include Win32 based utilities/stuff anyways for the higher up stuff. Having those other libraries would be more like trying to emulate Linux distros and would have nothing to do with ReactOS' primary objective, which is to be a replacement for Windows.

Posted: Sat Nov 25, 2006 6:22 am
by bastetfurry
If thats the devs decision then its that way

Posted: Sat Nov 25, 2006 6:34 am
by maddog39
Okay then, then I guess that means I have to learn Win32 GUI programming then(even though every1 knows MS sux and blows the high heavens [my opinion anyway]). But would it make more sense maybe if someone like me developed a GTK+ wrapper that worked in ReactOS. Only because the GTK+ runtime currently doesnt work at all in ReactOS, it crashes on installation or it refuses to run.

Posted: Sat Nov 25, 2006 6:40 am
by Z98
Well, eventually, once ReactOS is more complete, the GTK+ runtime should work. Remember, ROS is an incomplete operating system. It's missing a lot of things that Windows would have. That's the reason so many things don't work. The nice thing about ReactOS is that it removes the need to "port" things over. Once they implement everything they can, then any normal Windows application will run just fine.

Of course, certain bad (Norton) AVs will probably not work, but hey, that's no loss.

Posted: Sat Nov 25, 2006 6:54 am
by maddog39
Haha, yea Norton sucks. Alright, well as soon as I reinstall windows xp on VMWare I can get VS installed and mess with the Win32 GUI toolkit a bit.

Posted: Mon Jan 01, 2007 9:53 pm
by nute
What does it take to kernel program? References please. Do I need to wait till the audit is done before I can trust the Reactos source code?

Posted: Mon Jan 01, 2007 10:53 pm
by madmax69
nute wrote:What does it take to kernel program? References please. Do I need to wait till the audit is done before I can trust the Reactos source code?
Do you mean "trust" as in trust not to be sued by Microsoft or "trust" as in not to crash and corrupt your data?

As I understand, the auditing process is to ensure legal and copyright complicance not nesc. for software QA assurance or mathematical code "proof". (i.e. as a mark of software reliability).

I'm just a basic C programmer and not involved in ROS development but writing a kernel is not a trivial task if for no other reason that it involves real-time programming techniques and due to the global scarcity of really good R/T programmers out there. I skirted the issues of deadlock, threads, processing, queues, scheduling and pre-emptive multi-tasking during my undergraduate course and basic O/S design so I certainly wouldn't underestimate the difficulty of writing kernel code (let alone bullet-proof reliable code).

According to the Linux guys even star products such as Fedora aren't yet finished or 100% quality level yet and even the reliable linux 2.x kernels will have plenty of revisions and bugfixes to come.

I'm still waiting for a reliable ROS release so I can get testing Apache and a number of other networked apps on it!

There's only one true rule - there's always one more bug!. ;)

Posted: Mon Jan 01, 2007 11:18 pm
by hto
I'm still waiting for a reliable ROS release so I can get testing Apache and a number of other networked apps on it!
You can help with testing / debugging to make it more reliable. I think it is not necessary to wait when ReactOS will be stable.

Posted: Mon Jan 01, 2007 11:22 pm
by Z98
Learning how to program kernels by yourself or even with a book is extremely difficult. First, you'll need a basic understanding of the hardware, such as memory, registers, I/O, and a few other details. Then, you'll need to learn a bit of assembly. Then, you'll need to know how to program in C. I have bits of all three but there's no way I would understand kernel code yet. I would suggest start with C programming. It's actually the easiest of the three, in my opinion. But if you have a good understanding of those three aspects, then you can learn actual OS programming. Yeah, the three above are basically prerequisites.

Posted: Mon Jan 01, 2007 11:32 pm
by madmax69
hto wrote:
I'm still waiting for a reliable ROS release so I can get testing Apache and a number of other networked apps on it!
You can help with testing / debugging to make it more reliable. I think it is not necessary to wait when ReactOS will be stable.
I'd love to but after umpteen installs I still can't get ROS to stay free of BSOD for more than a few minutes and I've already posted elsewhere about the lack of useful screen information to feedback during failed boot up. Nice graphic but text trace would be more useful at this early Alpha stage (just MHO).

I suspect that there might be some problem with the TCP/IP stack as it seems to BSOD during file downloads - either via web browser or via command-line FTP client. I haven't worried too much yet as I understand it's very early days.

I haven't got enough room to install another tower unit to dedicate to ROS - I have QEMU and some old Tosh Laptops but I can't even get ROS to boot on them (not even using Smart Boot Manager).

I'm not really keen on compiling a debug version then piping debugging output via a serial port lol!!

I did a Win32 Micro Apache distro which is GPL - uses std components and weighs in at about 800kb for a fully-useful distro with PHP 4 but cannot get it into a ROS environment to test it. Also did a distro for BartPE but it hasn't had much interest. Apache 1.3.x can be cut down to about 300kb and still be usefully functional and 100% GPL. ;)

Posted: Tue Jan 02, 2007 12:18 am
by Durel
After playing around some more i can safely say its already quite stable for me. i just cant do muchw ith it since i cant get it online (or in my network for that matter) BUT! it doesnt crash so far so meh.

Posted: Tue Jan 02, 2007 12:50 am
by madmax69
Correct me if I am wrong but ...

I think that only NE2000 (or equivalent - e.g. RealTek) clone cards are supported at the moment. Should be easy to get hold of an NE2000 clone. With the right card in networking should work okay although my own experience was that it tends to spontaneously combust on downloading large(ish) files using FTP etc.

To be expected at this early stage whilst a lot of work is going off on the kernel and TCP stack.

Get hold of QEMU which emulates a complete PC and has a built in RealTek/NE2000 clone card emulated with it. Its also free and can run Linux, Novell Netware, XP, 2K, NT or pretty well any PC based O/S you want. ;)

-- EDIT --
Looking thru the INF section of the CDROM I also see there are drivers for AMD PCNET, RealTek 8029 based cards and ISA NE2000 cards
------------

Posted: Tue Jan 02, 2007 4:17 am
by hto
Learning how to program kernels by yourself or even with a book is extremely difficult. First, you'll need a basic understanding of the hardware, such as memory, registers, I/O, and a few other details. Then, you'll need to learn a bit of assembly. Then, you'll need to know how to program in C. I have bits of all three but there's no way I would understand kernel code yet. I would suggest start with C programming. It's actually the easiest of the three, in my opinion. But if you have a good understanding of those three aspects, then you can learn actual OS programming. Yeah, the three above are basically prerequisites.
Not so terrible as it sounds.
You can help with testing / debugging to make it more reliable. I think it is not necessary to wait when ReactOS will be stable.
I'd love to but after umpteen installs I still can't get ROS to stay free of BSOD for more than a few minutes and I've already posted elsewhere about the lack of useful screen information to feedback during failed boot up. Nice graphic but text trace would be more useful at this early Alpha stage (just MHO).

I suspect that there might be some problem with the TCP/IP stack as it seems to BSOD during file downloads - either via web browser or via command-line FTP client. I haven't worried too much yet as I understand it's very early days.

I haven't got enough room to install another tower unit to dedicate to ROS - I have QEMU and some old Tosh Laptops but I can't even get ROS to boot on them (not even using Smart Boot Manager).

I'm not really keen on compiling a debug version then piping debugging output via a serial port lol!!
Compiling debug versions is not difficult and piping debugging output via a serial port is not necessary.

I already tired to wait when all bugs will be fixed and decided to do some work myself... :)

Posted: Tue Jan 02, 2007 7:38 am
by frik85
madmax69 wrote:I'd love to but after umpteen installs I still can't get ROS to stay free of BSOD for more than a few minutes and I've already posted elsewhere about the lack of useful screen information to feedback during failed boot up. Nice graphic but text trace would be more useful at this early Alpha stage (just MHO).
Try out non-release versions which allow you to boot ReactOS in debug mode. Instead of showing the boot splash screen yu will see debug output, and you can also output the debug output to com1, etc.

Posted: Tue Jan 02, 2007 3:10 pm
by Dr. Fred
frik85 wrote:
madmax69 wrote:I'd love to but after umpteen installs I still can't get ROS to stay free of BSOD for more than a few minutes and I've already posted elsewhere about the lack of useful screen information to feedback during failed boot up. Nice graphic but text trace would be more useful at this early Alpha stage (just MHO).
Try out non-release versions which allow you to boot ReactOS in debug mode. Instead of showing the boot splash screen yu will see debug output, and you can also output the debug output to com1, etc.
No default is too COM1 now. I don't know who changed it. How ever you can change it to screen.