DOS ain't dead - DJGPP love Window$ ?

iw2evk

Magenta (Italy),
14.09.2013, 14:07

DJGPP love Window$ ? (Developers)

Hi,

i've a beginner question :
i've installed the same djgpp distro from

http://code.google.com/p/nanox-microwindows-nxlib-...wnloads/detail?name=djgppn.zip&can=1&q=

from Georg Site on 2 different pc.

On my workplace i running Window$ XP without administrator privilege, on my dos bworkplace at home i run freedos 1.1.

I've compiled for test infozip UNzip on both PC and djgpp .

In workplace i've loaded startc.bat config file and i've build the executable at first time, at home with same .bat files and package i receive a lot of error message.

I suppose somethink don't work during the serching of files required, may be because doslfn don't report the exact longfilename?

Someone have some problem?

Thanks

Roberto iw2evk

georgpotthast

Germany,
14.09.2013, 18:08

@ iw2evk

DJGPP love Window$ ?

Post reply

Hi Roberto,

did you enable long file name support on your DOS PC? DJGPP will not compile without that!

You can load doslfn and then it will compile, but MUCH, MUCH slower than in a Windows XP DOS box. So I develop in a Windows XP DOS box or I would never get finished. I did not try it for a long time but I think it would take over an hour to compile Dillo in real mode DOS with doslfn loaded.

I guess one could copy the required files to an XMSDISK and develop there but I did not try that yet.

Georg

> Hi,
>
> i've a beginner question :
> i've installed the same djgpp distro from
>
> http://code.google.com/p/nanox-microwindows-nxlib-...wnloads/detail?name=djgppn.zip&can=1&q=
>
> from Georg Site on 2 different pc.
>
> On my workplace i running Window$ XP without administrator privilege, on my
> dos bworkplace at home i run freedos 1.1.
>
> I've compiled for test infozip UNzip on both PC and djgpp .
>
> In workplace i've loaded startc.bat config file and i've build the
> executable at first time, at home with same .bat files and package i
> receive a lot of error message.
>
> I suppose somethink don't work during the serching of files required, may
> be because doslfn don't report the exact longfilename?
>
> Someone have some problem?
>
> Thanks
>
> Roberto iw2evk

iw2evk

Magenta (Italy),
14.09.2013, 18:48

@ georgpotthast

DJGPP love Window$ ?

Post reply

Hi Georg,

yes, when compile with djgpp in freedos before start startc.bat i load doslfn.
But i don't see on screen the longfilename under freedos also with loaded doslfn( why?).
In my win workplace djgpp use native lfn and run without problem ( i've compiled my 1st binary on my work pc , at home i've spent many hous without any result!)
But the way on workplace i can't spent time playng with djgpp : ((
So i can't try to learnig more about compiling in djgpp..

Laaca

Czech republic,
15.09.2013, 07:38

@ iw2evk

DJGPP love Window$ ?

Post reply

DOSLFN has slow writes. It is not so markant on normal 8+3 files (although some slowdown is present) but on true LFN files it is quite a lot. (the longer filename the slower writes). Especially big problems has DOSLFN when writting entries like SOME_VERY_LONG_FILENAME_1.dat, SOME_VERY_LONG_FILENAME_2.dat and so on. Diskcache helps but not so much because usually only reads are cached - not writes.
(maybe is worth to try HyperDisk cache /has some support for writes/ or a combination HyperDisk+UIDE)

---
DOS-u-akbar!

georgpotthast Germany, 15.09.2013, 09:10 @ iw2evk	DJGPP love Window$ ? Post reply
	> But i don't see on screen the longfilename under freedos also with loaded > doslfn( why?). The version of djgpp you downloaded uses LFN. So you should try to get that to work.

Laaca

Czech republic,
15.09.2013, 12:13

@ iw2evk

DJGPP love Window$ ?

Post reply

> But i don't see on screen the longfilename under freedos also with loaded
> doslfn( why?).

DIR command from FreeDOS's COMMAND.COM does not show LFN entries by default even with DOSLFN loaded.
You have to write DIR *.* /lfn

---
DOS-u-akbar!

bocke 16.09.2013, 02:54 @ Laaca	DJGPP love Window$ ? Post reply
	> DIR command from FreeDOS's COMMAND.COM does not show LFN entries by default > even with DOSLFN loaded. > You have to write DIR . /lfn I was wondering about that. Thanx. :)

Rugxulo

Usono,
14.09.2013, 20:36

@ georgpotthast

DJGPP love Window$ ?

Post reply

> did you enable long file name support on your DOS PC? DJGPP will not
> compile without that!

DJGPP intentionally can (and does) work with either LFNs (Win95) or no LFNs (MS-DOS 6.22). It totally depends on whether you unzipped (installed) DJGPP with an LFN-aware unzipper (and suitable TSR loaded, of course). If you want to use DJGPP with both SFN and LFN, you'll have to unzip twice. So some (but not all) files like "longfilename.txt" will exist twice as "longfile.txt" and "longfi~1.txt".

But most programs that people try to compile with DJGPP require LFNs and lots of POSIX tools (e.g. Bash for configure). So it may not "work" even if you do everything 100% correctly. Most modern programs just aren't designed to care about anything like DJGPP. But that is their problem (by design or ignorance), not ours.

> You can load doslfn and then it will compile, but MUCH, MUCH slower than in
> a Windows XP DOS box.

A while back, Juan recompiled DJGPP libc from CVS and timed it. It was actually 2x slower with LFNs than without.

> So I develop in a Windows XP DOS box or I would never
> get finished. I did not try it for a long time but I think it would take
> over an hour to compile Dillo in real mode DOS with doslfn loaded.

DJGPP is not fast. Or I should say GCC isn't very fast. You really need a cache loaded. And even then, a lot of it is still slower than ideal because it has to load lots of files to RAM from hard drive. Also, I'm not sure the linker is very optimal. It tries to do a billion optimizations, and it's not really geared towards compiling without it. In other words, you'd expect it to be 10x faster without optimizations, but it's not. If compile speed is important, DJGPP may not be for you. (Though careful use of makefiles can help prevent rebuilding unnecessary parts. You should really only recompile what's changed.) Oh yeah, lack of precompiled headers, blah blah blah. "Just use FPC!" ;-)

> I guess one could copy the required files to an XMSDISK and develop there
> but I did not try that yet.

Yes, a year ago I timed (re)compiling p7zip (G++) under bare FreeDOS with and without LFNs, both with compiler installed to RAM disk and traditional hard drive install. The fastest way was a). without LFNs (but needed lots of patching to the project, which always assumed certain names), and b). compiler itself installed to RAM (easily 2x or 3x faster than only cache + HD install).

iw2evk

Magenta (Italy),
15.09.2013, 09:13

@ Rugxulo

DJGPP love Window$ ?

Post reply

OK guys, i understand using djgpp on my dos only pc.
So i ask ..i've a puppy lucid linux pc : it's difficult create a cross compiler usind djgpp?

I've make some build with gcc under puppy with full success, so it's not a trouble it's possible setting up a cross compiler adding the required files?

The libraries used for build in dos remain the same used for build on linux?

I'ma little confusing regarding this mode of compiling bianries, but i 've understand most dos programs are build with cross compiling..

Thanks

Roberto

georgpotthast

Germany,
15.09.2013, 10:49

@ iw2evk

DJGPP love Window$ ?

Post reply

> OK guys, i understand using djgpp on my dos only pc.
> So i ask ..i've a puppy lucid linux pc : it's difficult create a cross
> compiler usind djgpp?
>
> I've make some build with gcc under puppy with full success, so it's not a
> trouble it's possible setting up a cross compiler adding the required
> files?
>
> The libraries used for build in dos remain the same used for build on
> linux?
>
> I'ma little confusing regarding this mode of compiling bianries, but i 've
> understand most dos programs are build with cross compiling..
>
> Thanks
>
> Roberto

I do not think cross compiling will be easier. Also when I make a program in a Windows XP DOS box I always have to make additional changes then so it will work fine in real mode DOS. So cross compiling for DOS with Linux and the result works just fine in real mode DOS - I doubt that.

What you could do is run Qemu on Puppy and have a FreeDOS image with djgpp for that - this should work.

Georg

Rugxulo

Usono,
15.09.2013, 20:32

@ georgpotthast

DJGPP love Window$ ?

Post reply

> > OK guys, i understand using djgpp on my dos only pc.
> > So i ask ..i've a puppy lucid linux pc : it's difficult create a cross
> > compiler usind djgpp?

In theory, not difficult. In practice, often yes. That's because of no interest upstream (or even barely downstream), hence it's not really a well-tested setup. Most of the focus is on other platforms, so it probably needs patches (e.g. check GCC481S.ZIP, not the official GNU sources, there's some minor differences).

> > I've make some build with gcc under puppy with full success, so it's not
> a
> > trouble it's possible setting up a cross compiler adding the required
> > files?

I think the compiler proper must be configured for target. Then you need cross-binutils (assembler, linker, etc.) as well as libs, headers, auxiliary tools, etc.

> > The libraries used for build in dos remain the same used for build on
> > linux?

The DJGPP libraries are still needed to (cross-)link DOS binaries atop a Linux host, yes. No, DJGPP doesn't (usually) use Linux ELF, so you can't (usually) mix COFF and ELF.

> > I'ma little confusing regarding this mode of compiling bianries, but i
> 've
> > understand most dos programs are build with cross compiling..

Not all programs are cross-compiled, no. But sadly most people find it easier to just assume LFNs, and for many years the easiest way was to just use NTVDM. However, that is deprecated to hell and back, so it's mostly not relevant nor very useful anymore. Though if you have XP, use it, enjoy, but XP is mostly phased out these days (and successors are worse for DOS).

So you can natively build things, and that is probably (IMHO) a preferred way, but most projects don't. Especially things like "./configure && make" rely on Bash and lots of POSIX utils (grep, awk, sed, coreutils), and ./configure (for whatever reason) doesn't natively work in Bash atop pure DOS, even with LFNs enabled (though DOSEMU is mostly okay).

> I do not think cross compiling will be easier. Also when I make a program
> in a Windows XP DOS box I always have to make additional changes then so it
> will work fine in real mode DOS. So cross compiling for DOS with Linux and
> the result works just fine in real mode DOS - I doubt that.

The DPMI host in Windows is different than that used in DOS. Sometimes that can be a problem, but for normal use it should be fine. DJGPP v2 exclusively uses DPMI (with wrappers around other memory types in pure DOS behind the scenes). If you don't do anything extender specific (and avoid bugs), you'll be okay, hopefully. :-)

You can (in theory) cross-compile bit-exact binaries the same as in pure DOS. Like I said, I build p7zip in several ways, and the md5sum of the .EXE matched exactly since I used the same exact tools and libraries. But often that's not feasible (without lots of patching) because it wasn't directly tested (by design or ignorance) in raw DOS. Well, it's a bit naive to expect a POSIX port of 7-Zip to support much (if any) DOS since DOS really isn't POSIX. I'm just saying, bad assumptions are the bane of portability.

> What you could do is run Qemu on Puppy and have a FreeDOS image with djgpp
> for that - this should work.

You could run DOSEMU with latest DJGPP (but use "dpmi -m 0x7FFFF" first, or similar). Or you can use a cross-compiler. I've used both. There's a slightly older (but still good) prebuilt DJGPP cross-compiler (G++ 3.4.6) for Linux host (and yes, I've used it under Lucid Puppy 5.x) at the Hammer of Thyrion (uhexen2) project, built by Ozkan Sezer:

http://sourceforge.net/projects/uhexen2/files/HoT%20-%20Support%20Files/cross%20compilers/

cross-djgpp-20111002-gcc346.tgz 2011-10-03 16.6 MB

bocke

16.09.2013, 02:53

@ Rugxulo

DJGPP love Window$ ?

Post reply

> In theory, not difficult. In practice, often yes.
>

I can confirm that. Had problems with it several times. For example: there are no recent docs. The available ones are obsoleted by a more than a decade.

Also, no clear 'downstream' patches to GNU tools. You must decrypt what did those who made it do. Example: reading spec files from Andris's SRPMs.

So, it's more to lack of the support and maintainance stuff on the DJGPP side. But, I can understand that, it's not like they have a lot of contributors. So, no blame to none, it is like it is...

georgpotthast

Germany,
15.09.2013, 10:14

@ Rugxulo

DJGPP love Window$ ?

Post reply

> Most modern programs just aren't designed
> to care about anything like DJGPP. But that is their problem (by design or
> ignorance), not ours.
>
Since I try to port these programs to DOS this is a big problem for me. Even programs that used to support djgpp drop djgpp support now since they see no reason for supporting djgpp any more and probably can no longer test it.

>
> DJGPP is not fast. Or I should say GCC isn't very fast. You really need a
> cache loaded. And even then, a lot of it is still slower than ideal because
> it has to load lots of files to RAM from hard drive. Also, I'm not sure the
> linker is very optimal. It tries to do a billion optimizations, and it's
> not really geared towards compiling without it. In other words, you'd
> expect it to be 10x faster without optimizations, but it's not. If compile
> speed is important, DJGPP may not be for you. (Though careful use of
> makefiles can help prevent rebuilding unnecessary parts. You should really
> only recompile what's changed.) Oh yeah, lack of precompiled headers, blah
> blah blah. "Just use FPC!" ;-)

In Windows XP I do not complain about the speed of gcc compiling a program. Yes, if you are using a makefile only the modified file will be compiled and then the package linked again, this can also be done in real mode DOS without leaving the PC for a cup of coffee.

I just did s speed test on my PC compiling complete Dillo:
Windows XP DOS box: 2 Minutes, 9 Seconds
Real Mode DOS: 24 Minutes, 43 Seconds.

>
> > I guess one could copy the required files to an XMSDISK and develop
> there
> > but I did not try that yet.
>
> Yes, a year ago I timed (re)compiling p7zip (G++) under bare FreeDOS with
> and without LFNs, both with compiler installed to RAM disk and traditional
> hard drive install. The fastest way was a). without LFNs (but needed lots
> of patching to the project, which always assumed certain names), and b).
> compiler itself installed to RAM (easily 2x or 3x faster than only cache +
> HD install).

I tried now to copy djgpp and the dillo source to an xmsdisk. Howver, that did not work since I could not get doslfn to support long file names on the xmsdisk.

Georg

Rugxulo

Usono,
15.09.2013, 20:08

@ georgpotthast

DJGPP love Window$ ?

Post reply

> Since I try to port these programs to DOS this is a big problem for me.
> Even programs that used to support djgpp drop djgpp support now since they
> see no reason for supporting djgpp any more and probably can no longer test
> it.

Anybody who says they can't test is a liar. We have several ways of testing (RUFUS, DOSEMU, VirtualBox). The simple truth is they don't care (or maybe just aren't experienced enough to actually make it work).

> I just did s speed test on my PC compiling complete Dillo:
> Windows XP DOS box: 2 Minutes, 9 Seconds
> Real Mode DOS: 24 Minutes, 43 Seconds.

There's no way this is optimal. Like I said, I compiled p7zip much faster atop a RAM disk (compiler included) with SFNs than even with DOSEMU under Linux.

But I've never rebuilt Dillo, so I don't know how easy it would be. But it certainly shouldn't be anywhere near that slow, trust me.

> I tried now to copy djgpp and the dillo source to an xmsdisk. Howver, that
> did not work since I could not get doslfn to support long file names on the
> xmsdisk.

Try Jack's RDISK, that's what I use, and it works with DOSLFN fine.

RayeR

CZ,
16.09.2013, 13:45

@ Rugxulo

DJGPP love Window$ ?

Post reply

> Anybody who says they can't test is a liar. We have several ways of testing
> (RUFUS, DOSEMU, VirtualBox). The simple truth is they don't care (or maybe
> just aren't experienced enough to actually make it work).

It's simply time consuming. Not impossible but require some effort that only few users will utilize it. Look at Adobe, they even told that they cannot longer test their SW under Windows XP so they dropped support for this (and older) Windows. And I guess that XP user vs Win7+Vista are maybe still 2:3 not 1:1000000 as in case of DOS...
Also problem is that DJGPP libC is not developing for 10 years and there was added some new functions and macros to current libC/libM version and as software is developing it utilizes more of new functions that libC/libM provides don't looking back...

---
DOS gives me freedom to unlimited HW access.

georgpotthast

Germany,
16.09.2013, 20:56

@ Rugxulo

DJGPP love Window$ ?

Post reply

> There's no way this is optimal. Like I said, I compiled p7zip much faster
> atop a RAM disk (compiler included) with SFNs than even with DOSEMU under
> Linux.

I agree that this is not optimal since it is taking far too long but I found that doslfn slows everything down a lot and you compiled p7zip with SFN as you write. So I think doslfn is the main reason for this long compile time. But I cannot compile Dillo with SFN.

I will try RDISK as you recommended too.

>and ./configure (for whatever reason) doesn't natively work in Bash atop
>pure DOS, even with LFNs enabled

I cannot say I have no trouble with ./configure since the config file usually assumes XLib etc but I have used the configure program that comes with djgpp successfully on several projects.

Rugxulo

Usono,
01.10.2013, 08:25

@ georgpotthast

DJGPP love Window$ ?

Post reply

> I agree that this is not optimal since it is taking far too long but I
> found that doslfn slows everything down a lot and you compiled p7zip with
> SFN as you write. So I think doslfn is the main reason for this long
> compile time. But I cannot compile Dillo with SFN.

I could not compile p7zip without LFNs except by a fair bit of patching. Of course it's not impossible, but most people don't have the patience or interest, I suppose, to support such a thing, esp. not for marginal speed gains.

But I did rediscover my old benchmark timings, for your reading pleasure (from freedos-user circa Sep. 2012, "HD I/O speed"):

http://www.mail-archive.com/freedos-user@lists.sourceforge.net/msg13098.html

> I will try RDISK as you recommended too.
>
> >and ./configure (for whatever reason) doesn't natively work in Bash atop
> >pure DOS, even with LFNs enabled
>
> I cannot say I have no trouble with ./configure since the config file
> usually assumes XLib etc but I have used the configure program that comes
> with djgpp successfully on several projects.

It only barely works in NTVDM or DOSEMU, so I don't trust it. Well, and it's too POSIX oriented, not something I really want to promote exclusively. (Windows devs still have to patch bad assumptions due to that. Though they probably make their own errors as well.) Oh, did I mention it's horribly bloated too?

marcov

16.09.2013, 19:58

@ georgpotthast

DJGPP love Window$ ?

Post reply

> > Most modern programs just aren't designed
> > to care about anything like DJGPP. But that is their problem (by design
> or
> > ignorance), not ours.
> >
> Since I try to port these programs to DOS this is a big problem for me.
> Even programs that used to support djgpp drop djgpp support now since they
> see no reason for supporting djgpp any more and probably can no longer test
> it.

(echos of the 16-bit FPC discussion in this post)

One could argue that it is the Dos users principal stance that causes it.

Maybe efforts should have been focussed more on keeping DJGPP a prime target rather than wasting much effort on keep DJGPP also dos hosted.

Rugxulo

Usono,
02.10.2013, 22:52

@ marcov

DJGPP love Window$ ?

Post reply

> (echos of the 16-bit FPC discussion in this post)
>
> One could argue that it is the Dos users principal stance that causes it.
>
> Maybe efforts should have been focussed more on keeping DJGPP a prime
> target rather than wasting much effort on keep DJGPP also dos hosted.

You may also be interested in reading this (Re: false "Perl is dead" meme):

http://allisonrandal.com/2013/03/31/mythbusters-why-i-still-love-perl/

Rugxulo Usono, 05.10.2013, 22:50 @ Rugxulo	DJGPP love Window$ ? Post reply
	> You may also be interested in reading this (Re: false "Perl is dead" > meme): > > http://allisonrandal.com/2013/03/31/mythbusters-why-i-still-love-perl/ Found another article about "xyz is dead" except this time it's more advocating switching to "better" alternative: http://steve-yegge.blogspot.com/2008/04/xemacs-is-dead-long-live-xemacs.html

Rugxulo

Usono,
20.10.2013, 00:55

@ Rugxulo

DJGPP love Window$ ?

Post reply

http://www.pascal-central.com/ppl/chapter4.html#Myths

> The culture of Pascal is oriented unapologetically toward readability
> in style, elegance of algorithm, and its expression as code. The
> culture of C is self-consciously ambitious, yet obfuscatory. This is
> illustrated quite well by C. A. R. Hoare in an introduction to the
> classic paper, An Axiomatic Definition of the Programming Language
> Pascal, for the book, Great Papers in Computer Science. In reference
> to his goal of designing a better programming language - one which
> makes it easier to write correct programs and harder to write incorrect
> ones - Hoare writes, "It is a matter of continuing regret that so few
> languages have ever been designed to meet that goal, or even to make
> significant concessions towards it. For example, the programming
> language C was designed to assist in writing a small single-user
> operating system (UNIX) for a real-time minicomputer (PDP 11), now
> thankfully obsolete. For this purpose, its low level of abstraction
> and plethora of machine-oriented features are entirely appropriate.
> For all other purposes, they are a nuisance. The successful
> propagation of the language can be explained by accidental, commercial,
> historical, and political factors; it is hardly due to any inherent
> quality as a tool for the reliable creation of sophisticated programs."

http://www.pascal-central.com/compare.html

> Pascal will die only if programmers let it die. Cries for its death
> do not offer any justification for its demise other than inertia.
> Our goal should not be to adopt the "winner", but to use the best
> tool available. After all, that's why we use Macintosh. -- Jim Phillips

Please disregard any bias (good or bad) regarding C, Pascal, Mac mentioned here. Obviously that was not my point in quoting these. You can substitute your own favorites there. The point is that you can defend (or criticize) anything if you try hard enough. But saying "xyz isn't useful for anyone doing anything anywhere anymore" is being overly pessimistic. (And often technically incorrect since the subtleties aren't obvious unless you actively use it. But often people are passively indifferent or even actively but irrationally hostile to competing tech, hence why we have so many vendors, versions, forks, etc.)

Rugxulo

Usono,
20.10.2013, 01:59

@ Rugxulo

DJGPP love Window$ ?

Post reply

And just for comparison and completeness (but moreso impartiality):

http://cm.bell-labs.com/who/dmr/hopl.html

"Pascal is very elegant. It's certainly still alive. It is prolific of successors and it has influenced language design profoundly." -- Dennis Ritchie (circa 1993)

Unfortunately, it's not obvious to most people that all languages have various dialects, standards, implementations, and dependencies. So nothing is perfectly supported everywhere. TIOBE still gives #1 as C, but that's only 17%. In other words, it's far from universal. But I still say "whatever works" is good enough.

marcov

20.10.2013, 21:28

@ Rugxulo

DJGPP love Window$ ?

Post reply

I'm really missing what you are trying to quote here. Some quotes (like the pascal central ones are totally warped out of context (those mostly were a historic reflection on Pascal on Mac, before GPC and FPC entered the picture there)

And my remark had nothing to do with C vs Pascal, but about Dos developers not supporting tools that have a chance of survival, but conservatively sticking to old sentiments (like binary size, 16-bit, development on dos itself etc, which is what I meant with the 16-bit FPC discussion reference) and tools till it is too late.

So to put it clear: I think that much too much resources to develop for dos go into doing it on dos.

Rugxulo

Usono,
22.10.2013, 01:17

@ marcov

DJGPP love Window$ ?

Post reply

> I'm really missing what you are trying to quote here. Some quotes (like the
> pascal central ones are totally warped out of context (those mostly were a
> historic reflection on Pascal on Mac, before GPC and FPC entered the
> picture there)

Everyone has an opinion. There are already too many arguments about "us" vs. "them". It's irrational. On a purely technical level, it either works or it doesn't. But people can't even get the facts straight. They don't know, and they don't want to know. At best, it's passive indifference.

> And my remark had nothing to do with C vs Pascal, but about Dos developers
> not supporting tools that have a chance of survival, but conservatively
> sticking to old sentiments (like binary size, 16-bit, development on dos
> itself etc, which is what I meant with the 16-bit FPC discussion reference)
> and tools till it is too late.
>
> So to put it clear: I think that much too much resources to develop for dos
> go into doing it on dos.

It's not really true that "nobody stepped up" or "it doesn't work" or "it's dead". Some people actively and directly destroy things that are within their power to destroy. Things that work, are fully supported, have volunteers and testers (and patches, bugfixes, binaries). There's literally nothing you can do for some people, they reject any form of help because it doesn't fit their agenda. And they publicly and officially remove any support for competing tech because of that. Which makes things that much harder (even if you consider it fully within their legal rights, which I'm sure you do), even if you can (sometimes) fork and maintain privately. I just find it more than a little rude and dishonest, esp. when people still say the same old myths. I'm sorry, but destroying something that 99% (or 100%) already works feels wrong to me. It's just not true that nobody tried to help. Some projects won't accept help, they would rather directly destroy. It's technically called a "downgrade" to make things worse. It's not that "xyz is dead" but that "abc killed their own subproject using xyz" because it didn't fit their agenda.