Hi folks,
did you already implement an replacement for the IE libraries
(and if not: is this planned anyway ?)
If I understood you correctly (at least in the discussions we
had last year), you're implementing the win32 APIs as exact
as possible. So would (at least the userland stuff) be
drop-in compatible with the orignal M$ code ?
It would be really nice to have dummies for the IE libraries,
to get IE off an Windows system, but remain it runnable.
Perhaps it would be even nicer to have IE libs using the
mozilla/gecko as backend ;-)
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact(a)metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
OK Richard, Now I understand ( I think).
I have a choice to start that "other project" or find it.
Well for the benefit of the listeners I have started it.
In the interests of [ros-general] please consider UAPI closed.
Any private suggestions are welcome.
Thanks and rosSuccess.
Justin
---- Richard Campbell <eek2121(a)comcast.net> wrote:
> Last i checked, the ROS design isn't designed to correct anything. It
> is designed to be a drop in replacement for Windows NT, 2000, XP that is
> compatible with applicatons and drivers. It is then up to other
> projects to mod that as they see fit.
>
> Richard
>
> Thomas Weidenmueller wrote:
>
> >jwalsh(a)bigpond.net.au wrote:
> >
> >
> >>The Original Windows is having anormous problems fighting off Virus and Malware.
> >>It is known that it's vunerability is builtin to its original design i.e. the TSR.
> >>Where does the ROS current design correct that inherent problem?
> >>
> >>
> >
> >If we can't run viruses designed for windows (except those exploiting
> >bugs), the level of compatibility is rather low...
> >
> >
> >
> >>If ROS is short staffed now how bad is it going to get, if and when things do take off.
> >>
> >>
> >
> >We're not going to have an OS that I would consider stable in the near
> >future. There are bugs and flaws everywhere you look, kind of the same
> >problem that wine has.
> >
> >
> >
> >>If a multi billion dollar enterprise cannot stop it how can ROS stop it?
> >>This is not a trivial question.
> >>
> >>
> >
> >Money can't fix everything, sometimes better decisions would help.
> >
> >- Thomas
> >_______________________________________________
> >ros-general mailing list
> >ros-general(a)reactos.org
> >http://www.reactos.org/mailman/listinfo/ros-general
> >
> >
> >
>
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
Ok Thomas. I am beginning to understand.
I'm a bit slow. I saw it as merely providing a more stable Foundation for ROS, that is all.
If you are so unknowing of OSI, and API and all that stuff now, and do not care, then I am wasting your time.
Sorry.
Frankly, the Universal API is still only an Idea which never got off the ground about 25 years ago (because of in-fighting), but still does work in isolated practice.
>From the Email I am getting there is so much disagreement on this list you will need all you time and effort to keep it from collapsing.
In your best interest, please consider this topic closed.
Regards and Success
Justin
---- Thomas Weidenmueller <thomas(a)reactsoft.com> wrote:
> jwalsh(a)bigpond.net.au wrote:
> > I'll switch to private mode, so as not to annoy the ros-general list.
> > It is a little off topic.
>
> I don't think that's a good idea, especially when I keep getting
> annoying spam approval emails which I won't approve.
>
> > I'll choose three references which I feel, by and large, describe the API.
> > The first also includes a reference to wine:
> > 1. http://www.absoluteastronomy.com/encyclopedia/a/ap/application_programming_…
> > 2. http://www.absoluteastronomy.com/encyclopedia/o/os/osi_model2.htm
> > 3. http://en.wikipedia.org/wiki/Layer_2
>
> I do know the OSI model and I do know what APIs are. I however don't
> know what exactly the UAPI is supposed to be. We're working on a windows
> compatible operating system. We do not plan to add ReactOS-specific
> APIs, so whatever UAPI is, unless it's an API provided by Windows,
> there's a low chance we'd ever implement it into the core code base.
>
> > What we expect to do, is study the "rats nest" of protocols and reduces them to a single Universal OSI Standard. We believer that hardware must dance to the tune of software, not the opposite.
> > We have some success at the Application Layer (level 7) already.
> > Here we can reduce many hundreds of applications to a single application, automatically.
> > Then we simply print of the "blueprint" i.e. Application Requirements Definition (ARD).
> > We then simply pass the ARD to the programmers to be put into code.
> > This way we have turned a medievel like craft into an industrial process.
> > In fact we are preparing to generate the code directly from the text based ARD.
>
> We can't change existing hardware, ReactOS is supposed to work on the
> existing platforms. What you described is extremely theoretical, I still
> don't really know what it is supposed to be. Most of us - i think - are
> more practical people, give us the detailed description of how the API
> is supposed to look like and what it should provide and we can do it.
> Discussing theories about APIs that don't exist (in Windows) doesn't
> make much sense I think.
>
> > We have reduced application development from months-years to hours-days.
>
> That's great, for ReactOS this is just not going to work.
>
> > Unfortunately, no matter how perfect our design is, it can only be as good as the weakest link.
> > We've found that weakest link hidden in the API itself, outside of our control.
> > Of course the hardware providers will not be happy with this development.
>
> Which leads to the question whether hardware depends on software or the
> other way around...
>
> > Neither will the software providers who write the drivers.
> > It must be, if it is to be backward (and forward) compatible, transparent to the any and every application.
> > Wine, in a sense is trying to acheive the same thing, by not trying to create a single standard, but merely an API adapter.
>
> Wine is all about creating a compatible implementation of the Win32 API.
>
> > Sorry again for being so long winded.
> > Hope that explains it
>
> Not really, sorry ;)
>
> So my final question about this - and I don't plan to spend any more
> time about this - is: Is this UAPI thing just a theory or actually an
> API that exists?
>
> - Thomas
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
Hello All.
Just sending out an announcement that Issue 1 of the new ReactOS
Weekly Newsletter is now available for viewing on
http://www.reactos.org
Thanks to GvG for showing me the internals of RosCMS, Bac9 on #reactos
for helping with validation checks, and dnordenberg, again on
#reactos, for offering to help with the Newsletter in the form of an
XML-Based back-end, to come soon.
--
"I had a handle on life, but then it broke"
Good god...
"First off, judge yourself. Are you an experienced graphics
designer/artist with extensive icon experience? Have you ever made
icons included in other projects, such as at your day job, an open
source project, or similar? If you answered "no" to ANY of these
questions, please do not attempt to submit icons. Save yourself
humiliation, and save me the difficult task of turning you down. It's
not because I want to be mean, honestly. If you answered "yes" to all
of the above questions, please read on."
Is it just me or do anyone else get a _tad_ arrogant image from that?
This attitude has been a major setback, from the start, on my side and
it's starting to get under my skin again.
First of all, surely ROS isn't professional project, if it would be it
would have real funding etc. Besides, open source projects seldom are
for professionals only. In my point of view any kind of help would be
appreciated, but it seems that now only professionals can help.
Well, I think it's time to open up a bit.
mf: Last time, when I was about to lose it, you persistently you went
on (in forums and in IRC) how there is no "magical rules" and i.e. on
icon design and only rules applying are recognition and color use.
True; Recognition plays a cruicial role and it can be aided with
proper color use. False; There are other rules that need to be
considered, these are no less "magical" than say proper color use.
Well, for example, lets see your trashcan design:
http://www.mufunyo.net/reactos/trashcan.pnghttp://www.mufunyo.net/reactos/trashcan2.png
Now, can you tell me what's wrong with that desing? And in this case
I'm not referring to colors, shapes or anything like that...
-mikko
Hi all
I've decided that now is the best time to step down as Project
Coordinator. The process to vote for a new PC will be - as previously
decided for this type of decision - that only registered committers
can vote.
Regards
Jason
PS - I've cc'd the developers on leave as to not exclude anyone
Ok Thomas. I'll try and put it another way.
The Original Windows is having anormous problems fighting off Virus and Malware.
It is known that it's vunerability is builtin to its original design i.e. the TSR.
Where does the ROS current design correct that inherent problem?
If ROS is short staffed now how bad is it going to get, if and when things do take off.
If a multi billion dollar enterprise cannot stop it how can ROS stop it?
This is not a trivial question.
Thanks
Justin
---- Thomas Weidenmueller <thomas(a)reactsoft.com> wrote:
> jwalsh(a)bigpond.net.au wrote:
> > Hi Al.
> >
> > Please correct me if I am being too naive.
> > But what you have just said makes so much sense to me.
> > The windowblinds will in fact be a matter for the CGI; separating the Form from the Content.
> > I think I understand what you have said as being a kind of UAPI: Universal Application Programming Interface.
> > I did a quick google on the abbrieviation and it does not yet exist. Only API.
> > I hate inventing new terms when old ones serve just as well, if not better.
> > However it comes from my old hardware days when the second biggest chip on the board was the UART: Universal Asynchronous Receiver Transmitter.
> > It was cleverly reduced by TI to a tiny 16 pin package, the rest done with a special 4KB bit memory and a few instructions.
> > It (the "UAPI") does pretty much the same thing which the Ethernet OSI 7 Layer Model tries to do. So far it The API looks and feels like software but is actually softWire, cleverly disguised.
> > I no NOT mean softwire as another name for software.
> > Idealy the "UAPI" reduces 7 layers of Meta-drivers to one Application.
> > The use of the word Ether (like softwire) in the Network also lends false credence to the meaning of the API.
> > The Ether was once thought to be Matterial which conducted light i.e. a kind of invisible wire. We now know it to be mere a Mode of the existence of Matter.
> > Not an Object in the real sense but a purely Mental one.
> > The concept may serve the interest of the Hardware (wire) Industry but not ours.
> > Our R&D team is working on this now.
> >
> > Thanks for the the enlightening thought
>
> ok....what? Sorry, can't follow...
>
> - Thomas
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
jwalsh(a)bigpond.net.au wrote:
> I'll switch to private mode, so as not to annoy the ros-general list.
> It is a little off topic.
I don't think that's a good idea, especially when I keep getting
annoying spam approval emails which I won't approve.
> I'll choose three references which I feel, by and large, describe the API.
> The first also includes a reference to wine:
> 1. http://www.absoluteastronomy.com/encyclopedia/a/ap/application_programming_…
> 2. http://www.absoluteastronomy.com/encyclopedia/o/os/osi_model2.htm
> 3. http://en.wikipedia.org/wiki/Layer_2
I do know the OSI model and I do know what APIs are. I however don't
know what exactly the UAPI is supposed to be. We're working on a windows
compatible operating system. We do not plan to add ReactOS-specific
APIs, so whatever UAPI is, unless it's an API provided by Windows,
there's a low chance we'd ever implement it into the core code base.
> What we expect to do, is study the "rats nest" of protocols and reduces them to a single Universal OSI Standard. We believer that hardware must dance to the tune of software, not the opposite.
> We have some success at the Application Layer (level 7) already.
> Here we can reduce many hundreds of applications to a single application, automatically.
> Then we simply print of the "blueprint" i.e. Application Requirements Definition (ARD).
> We then simply pass the ARD to the programmers to be put into code.
> This way we have turned a medievel like craft into an industrial process.
> In fact we are preparing to generate the code directly from the text based ARD.
We can't change existing hardware, ReactOS is supposed to work on the
existing platforms. What you described is extremely theoretical, I still
don't really know what it is supposed to be. Most of us - i think - are
more practical people, give us the detailed description of how the API
is supposed to look like and what it should provide and we can do it.
Discussing theories about APIs that don't exist (in Windows) doesn't
make much sense I think.
> We have reduced application development from months-years to hours-days.
That's great, for ReactOS this is just not going to work.
> Unfortunately, no matter how perfect our design is, it can only be as good as the weakest link.
> We've found that weakest link hidden in the API itself, outside of our control.
> Of course the hardware providers will not be happy with this development.
Which leads to the question whether hardware depends on software or the
other way around...
> Neither will the software providers who write the drivers.
> It must be, if it is to be backward (and forward) compatible, transparent to the any and every application.
> Wine, in a sense is trying to acheive the same thing, by not trying to create a single standard, but merely an API adapter.
Wine is all about creating a compatible implementation of the Win32 API.
> Sorry again for being so long winded.
> Hope that explains it
Not really, sorry ;)
So my final question about this - and I don't plan to spend any more
time about this - is: Is this UAPI thing just a theory or actually an
API that exists?
- Thomas
Thanks Thomas, for your frankness.
I hope that this bit is true anyway.
> Money can't fix everything, sometimes better decisions would help.
We don't have any money either, so our decisions must be perfect.
If we do build this UAPI, it's GNU gpl that's for sure.
Good Luck and Success
Justin
---- Thomas Weidenmueller <thomas(a)reactsoft.com> wrote:
> jwalsh(a)bigpond.net.au wrote:
> > The Original Windows is having anormous problems fighting off Virus and Malware.
> > It is known that it's vunerability is builtin to its original design i.e. the TSR.
> > Where does the ROS current design correct that inherent problem?
>
> If we can't run viruses designed for windows (except those exploiting
> bugs), the level of compatibility is rather low...
>
> > If ROS is short staffed now how bad is it going to get, if and when things do take off.
>
> We're not going to have an OS that I would consider stable in the near
> future. There are bugs and flaws everywhere you look, kind of the same
> problem that wine has.
>
> > If a multi billion dollar enterprise cannot stop it how can ROS stop it?
> > This is not a trivial question.
>
> Money can't fix everything, sometimes better decisions would help.
>
> - Thomas
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
Hi Al.
Please correct me if I am being too naive.
But what you have just said makes so much sense to me.
The windowblinds will in fact be a matter for the CGI; separating the Form from the Content.
I think I understand what you have said as being a kind of UAPI: Universal Application Programming Interface.
I did a quick google on the abbrieviation and it does not yet exist. Only API.
I hate inventing new terms when old ones serve just as well, if not better.
However it comes from my old hardware days when the second biggest chip on the board was the UART: Universal Asynchronous Receiver Transmitter.
It was cleverly reduced by TI to a tiny 16 pin package, the rest done with a special 4KB bit memory and a few instructions.
It (the "UAPI") does pretty much the same thing which the Ethernet OSI 7 Layer Model tries to do. So far it The API looks and feels like software but is actually softWire, cleverly disguised.
I no NOT mean softwire as another name for software.
Idealy the "UAPI" reduces 7 layers of Meta-drivers to one Application.
The use of the word Ether (like softwire) in the Network also lends false credence to the meaning of the API.
The Ether was once thought to be Matterial which conducted light i.e. a kind of invisible wire. We now know it to be mere a Mode of the existence of Matter.
Not an Object in the real sense but a purely Mental one.
The concept may serve the interest of the Hardware (wire) Industry but not ours.
Our R&D team is working on this now.
Thanks for the the enlightening thought
Justin
---- Al Hartman <alhartman6(a)comcast.net> wrote:
> First of all, thanks to all of you for all your work on ReactOS.
>
> Secondly, why reinvent the wheel?
>
> Why not simply assure that ReactOS is compatible with WindowBlinds?
>
> http://www.stardock.com/products/windowblinds/
>
> I'm much more interested in ReactOS having Rock-Solid base functionality...
>
> - Printing
> - Networking
> - Speed
> - Compatibility with Apps.
>
> Rather than UI eye-candy.
>
> That stuff can come later, or by using the many third party skinning
> apps for Windows.
>
> Thanks!
>
> Al
>
>
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
