Be Developers' Conference Working with Intel Stephen Beaulieu

Stephen Beaulieu: All right. I welcome you to the extending track. This session is titled Working With Intel. I'm Stephen Beaulieu, currently one of the two Developer Technical Support engineers working with Be.

First, let's go over a group of things. Mainly this session is talking about differences between the PowerPC release, PR2, that hopefully most of you in the extended track will already have played with, and Release 3, specifically Release 3 for Intel.

This session is going to be nearly identical to the Approaching A Cross-Platform OS session later on this afternoon. So for starters, if you've attended this, instead of coming to see me, and getting the same talk again, definitely go see the BDirectWindow demonstration that's showing opposite. That will be a little bit more exciting.

Basically we're going to talk over various issues, compatibility between PR2, PowerPC, R3 and specifically PowerPC and x86, some coding issues, some development environmental issues. We'll go ahead again and start with compatibility issues.

For starters, we have made a big attempt to make sure that your code is compatible. For 99 percent of the code we have had people play with, it's a simple recompile from PowerPC to the x86, you know. Get it up and running, bring your code over, adjust your makefile, or your project file with things, which I'll talk about a little later. Make it, you've got a completely functioning app.

There are some things, and we'll go over some of the gotchas in a little bit, but most of the people, if you're doing plain old BeOS interface type things, if you're using our kits, most of the time it's just going to be a quick recompile to have it on both systems.

File contents, for example, are another place. If you had a data file, a text file on one platform or another, they will also be compatible. We'll get back to that in a moment. Now to talk about possible incompatibilities. One thing that obviously is incompatible between the two systems are the binaries. We use the PEF format (on PPC) and PE-COFF format (on x86), two different object formats. But more importantly, on the PowerPC side you generally have PowerPC instructions inside your application binary. On the Intel side, you have Intel instructions. We do not have a FAT application format. So if you're going to be developing for BeOS, we strongly encourage you to create both PowerPC and x86 binaries and we'll have to -- the same application obviously, but get an extra binary format and be aware in support that sometimes people might go to grab the PowerPC version on an Intel machine, that won't work.

Another thing, as we were getting ready, there were some things we didn't finish in time. One of the things was the file system compatibility. Basically what we had was the BFS internal file system structures are endian-dependent right now. So you cannot trade a floppy on BeOS for Intel. Take it over to your BeOS for PowerMac or BeBox. We don't know how to read that yet. We don't have that tool set up yet. That is something we're going to be working on. But again, I can't give you any dates. We're going to have that support. That, again, is an endian issue. We'll have a section on that in a moment.

Another thing that is endian-dependent are resource files. You can't take a resource file from PowerPC and use it on an Intel build. You need to have separate resource files. I will go ahead and go over that a little bit later.

So while you can't just move a hard disk around, while you can't move a floppy around, the contents of your files, for the most part, are still going to be compatible. So what can you do if you've got both systems and want to move it around? Network transfers. Zip and FTP are definitely your friends. FTP allows you to get files from one platform to another, written in the proper format. The Zip folks have gotten it up and of course Zip supports file system attributes for the BeOS. It does all it needs to do for byte swapping of attributes. So you can pack it up, move it over and unpack it, like you just moved it from one file system to another. Really the best way to go. Again, the file system and resource file incompatibilities, those are things we are working on, but we just don't have dates when those are going to be done.

Now, let's get into probably what most of you are caring about, which are the coding differences. As I said before, most code simply recompiles, which is great. That makes it very easy for you. That's how all our systems got up running after we got endian issues in the lower level. The recompiles were there. There are some exceptions.

One thing with the Metrowerks compiler you might have been used to -- in fact, we documented in the MessageReceived() function, at the end of it in your switch statement if you haven't found a message you know how to deal with, you should call 'inherited::' whatever the function is. The 'inherited' key word didn't make it into the ANSI spec and was pulled out of the Metrowerks compilers. You can pass a #pragma to the compilers to use it, but we strongly recommend you go ahead and replace it with a direct call to the appropriate parent class. That's one thing you'll probably run into that might stop the automatic recompile.

Obviously, the biggest thing you'll run into is byte order changes. There's also changes in importing and exporting symbols. We'll go to byte order first and cover some things.

In general, we're going to talk about Big-endian versus Little-endian platforms. We're going to talk about byte swapping in general. Different methods for tackling swapping of the bytes, natural versus canonical, and then when you actually need to swap.

So basically a basic runover of Big-endian versus Little-endian. How do they keep track of memory? Big-endian keeps track of multibyte data with most significant byte first and Little-endian with least significant byte first. Example, this one, the bytes are swapped. Fairly straightforward. Most of you guys hopefully understand that already.

So generally what that means is at some point in time to support different platforms you're probably going to have to swap some sort of data. We'll get into that in when to swap. Let's talk about how you can do it in the system. You need to swap multibyte data, floats, doubles, ints. And there are several actions you can take. On your host system, regardless of endian order you can swap to Big-endian, or to Little-endian. You can swap from either Big or Little-endian to the host format. Or you can always swap.

In the BeOS we provide some macros and functions to handle this. And the information on that can be found in the header file support/ByteOrder.h.

We'll go ahead with the macros. The macros we provide swap single units only: ints and floats like: double, int16, int64. Again, we have different macros, depending on what you want to do. So for doubles, floats, int64's, int32's, int16's, you can swap from host to Big-endian or Little-endian, from one byte order to host, or always swap. All of those actions there are macros defined in binary that handle all those individual units. That's pretty straightforward.

We also provide byte swapping functions for arrays of data or types. So, for example, if you've BRect, BRect has a bunch of different data in there. You can pass it to one of our functions called swap_data() that will go ahead and do the swapping for you. If you have an array of int64's, you can pass it and it will swap each one individually. That function is -- that is called swap_data where you pass the type_code, the type of data you're working with, you pass a pointer to that data. You basically pass it a size for how images that data is, if it was an int64, you would pass sizeof(int64). Also what type of action you want to swap. Again, the same thing we talked about earlier.

You can also -- we also have a function called is_type_swapped() that allows you to pass a type_code, BMessage, whatever, and returns whether swap_Data will swap that type.

So now we know that there is a difference between Little-endian and Big-endian. We know that. We have some functions to do the swapping. Let's talk about some methods, philosophies of how to make sure everything is swapped appropriately. There are two methods, natural or canonical swapping.

Natural swapping means you also write in whatever order your system is. If on x86 BeOS, you'll write Little-endian. If on PowerPC, write Big-endian. Set a single byte flag actually, not a multibyte, because that won't get swapped. That is a flag basically saying what order the file or data that you're dealing with is written in. Upon reading it, if that order is opposite from you, you go ahead and step over that and deal with it, swap it.

The other method is canonical swapping, which is always writing in a given byte order. If you are in a different byte order system, you would then have to swap for reading and swap when writing that data.

I'm going to go ahead and deal with the question that's probably likely to come up, which is which one is better, which one is more efficient. It really depends upon what you're doing. If you're writing something like an E-mail application that is likely to be prevalent on both platforms, natural order might not be a bad way to do it because if the E-mail is just staying on your system, this is reading the files as the E-mail comes in, for example, or if your word processor doesn't want to write information out, format in a data file, if that file is unlikely to leave the system, if most of the time it's going to be on one machine and not switched to another platform, use natural, as 9 times out of 10, you're going to be writing to a Little-endian system and reading back to another Little-endian system, or Big-endian as the case would be, and you don't have to do the swapping.

Other times it makes sense to go canonical where, for example, you have some hardware that only works on Power PC-related machines and so PowerPC-specific hardware, you'll never find it in an Intel box, or the other way around. Sometimes it makes sense to write Little-endian or Big-endian only and then only, you know, worry about it later.

So if the format is always written one way, you always know what order it's going to come back in because 99 percent of the time it's going to be in that one format. So there's no easy answer how to do it. It depends on the type of application you're working with, how often data is likely going to be moved to another system.

That gets us to when do you need to swap. In general, the data that you're writing could possibly be leaving or entering the system with a different byte order, you want to make sure you check swapping. The main places you run into this is writing a file because someone could copy that file or use network transfer to move it to another machine, or when you're sending information out to the Internet, for example, you don't know what's going to be receiving the packets on the other end. If you're just dealing with something that occurs in memory you never write, you just have, say, an int, that you use to keep track of things, a bit field, but never written out anywhere, you don't have to worry about swapping. It will only be in memory, only used in your system. It's only when you write it someplace, it could go somewhere else, that you have to worry about it. A lot of the cases you really don't have to worry about swapping.

The BeOS handles swapping of its own defined times. For example, when you take a BMessage and you flatten it either into a file or put it across the Net, the BeOS handles on unflattening all of the byte swapping for the known types in that message. You don't have to worry about it. We take care of it. File system attributes are swapped upon zipping. You move it across one platform to another, do the unzip, it will take care of the attribute swapping. You don't have to worry about it.

You are, however, responsible for swapping your defined types. So if you have a data file where you write just a series of floats, things like that, and you write it out to a file, the BeOS isn't going to know what to do with it. You're going to be responsible for handling that.

The same thing if you define a struct and tuck it into a BMessage somewhere. When the BMessage flattens, unflattens, it's not going to do anything with it. Generally, the best philosophy to go with is what the BeOS doesn't know about, it can't swap it. So don't count on it being done. It won't be.

We're done going over byte order now. The other main difference from PowerPC side is for importing and exporting symbols. We'll go into a little more depth and go back later.

One thing that's very different about Intel, PowerPC, is that the first time that the compiler runs across a declaration for a symbol, whether a class or function or global data, when it first runs across it, that's when it decides when it's going to be imported or exported, which is very different from the PowerPC which goes, my understanding, and looks through and finds where -- if it stumbles across it says, imported or exported, that's where it goes ahead. It's got a compile time, not link time on it, on the Intel side.

So you've got several methods of handling importing and exporting. We've got #pragma export and import. We've got export files also available in some PowerPC side and we've got from basically the Windows specification declspecing.

#pragma export is pretty simple. Declare in the header files: #pragma export on, then the symbol you want to export, and then #pragma export reset. The same thing with import. You don't really have to worry about import because on PowerPC it's assumed that symbols are going to be imported. If the symbol is there and you link it with something, it will automatically get imported for you. You don't have to specifically declare that. With Intel you have to specifically import a symbol. The default is it's an internal symbol not used either exported or imported, so the same thing with class function, global data, for #pragma import on.

One thing about all of these importing and exporting, these are all compiler-dependent. The C and C++ specs don't say anything about how to import and export symbols. So to a certain extent all of this is going to be compiler-dependent and all #pragmas are compiler-dependent. You can't count on, if someone were to come out with an Intel or PowerPC compiler for BeOS, you wouldn't be able to count on #pragmas necessarily working. Don't necessarily count on any of these working.

Export files. A couple different ways to do this. And I've got an error on this slide. Export files are the text file with the list of all the symbols. The format of the text files differ. On PowerPC we've got a .exp file that shows it one way. On the x86 side there are a couple different ones. .CMD files, that I've got written as a .COM file, and .def files are two different formats. Basically how you use an export file: you would first export all symbols. Then you go through and edit it to just include the symbols you wanted to go ahead and export. And then you would recompile again using that to define those exported. That's how you get your final product.

Declspec. For those of you unfamiliar with Windows, this is the main method that they have defined for importing and exporting symbols, global data and functions of classes of all types. It's fairly straightforward. It's __declspec(dllimport) to import symbols and __declspec(dllexport) to export symbols. Currently we are recommending this is the way you should import and export symbols using with the Be. Okay, the question now is why?

For one, because it is the Windows format which, you know, 95 percent of the computer world uses, chances are that the other people who are likely to come up with compilers for the BeOS are going to support it because they support it already. Another advantage is you don't have to change anything in the code. You can create basically a foward declaration file that lists all of the symbols you're going to import or export and you can create a macro that basically says, "If I'm building the library, I want to export the symbols." or "If I'm building an application that's linking its library including, say, header file, I'm going to import the symbols."

I've got an example on these foward declarations, a simple header file called impexp.h. That's how it works. It's important on the Intel side if you break these out like this and do a header file, that header file has to be the first thing that compiler sees, included first, because it will then list all -- everything -- all the data you want to export. Again, on the Intel side the first time it runs across the name of a symbol, that's how it decides what to do with it.

The reason why we're recommending this is it works on both Intel and PowerPC. It's very likely to be -- it's the most likely of the systems to actually be supported by other compilers when and if those become available. It also gives you a lot of direct control over how the symbol would work, over exactly what gets exported. You have one file where you need to add or delete symbols as necessary. You don't have to touch the code.

I'm sure there will be more questions on this that we'll go ahead and get to in the Q and A session.

I'll move on to development environment issues. It has changed a little bit. I've got another error on this thing, under compilers and linkers. On the PPC side and PR2 we were using them as mwldc and mwld. For R3 they've added an identifier for the platform. You have compilers and lnkers mmccppc and mwldppc for PowerPC, and compilers and linkers mwccx86 and mwldx86 for x86. The header file path is the same: /boot/develop/headers.

Link libraries are different. These are shared libraries that you link your applications against to export those symbols. You have another typo at the top. The link libraries path, differ on the two platforms, with a ppc folder, and ab x86 folder, for the Intel side.

On PowerPC you link against the run time libraries. If you want to link against libbe.so, you literally link against libbe.so. On x86 you link against a link library that exports symbols for link time, not run time. For shared libraries these link libraries have an additional LIB extension. We'll show you examples.

The standard link libraries have also changed. On the PowerPC side you would be used to linking against libdll.a. That's been broken up into three different parts. Both PowerPC and Intel, glue-noinit.a, init_term_dyn.o and start_dyn.o. These handle the dynamic linking code needed for your applciation. libbe.so has all the standard classes and libroot.so takes care of library management and the like.

Let's go ahead in a little more detail in resource files and their compatibility. This is an endian issue, again. We have a couple of tools that didn't make it on the CD like it was supposed to that I'll be releasing in the newsletter this upcoming week for resource conversions. They actually didn't get put there. We'll make these available from the Web. These tools are very, very limited resource converters, one that runs on the PowerPC side and one that runs on the Intel side. You will run it and it will take some information, generally application information and some BMessage information in there. And it will go ahead and convert those.

If you have resource files that have your own structures, if you pretty much do anything different from the standard it will not be converted and we have no way to convert those currently. What we are recommending people do is build your resources from scratch for Intel. It will just work a lot easier for you. It will mean that you have to have different resource files for both platforms.

Again, this is something that's very important for us that we want to make as easy as possible for you. There was not time for us, the time we needed to get R3 out. People were clamoring for Intel to get all these fixes in. I don't know when it's going to be done. I can't promise it will be done for R4, but I know we're going to try. It's very important for us.

Other issues dealing with Intel, cross-compilation and testing. With the new Metrowerks tools coming out to you and we will be providing, we do have binaries that will allow you from PowerPC, you will have a PowerPC binary that is mwccx86 that will output Intel binaries. Same thing on the x86, to create PowerPC binaries. Internally at Be these have not been tested. My understanding is they have been thoroughly tested by Metrowerks, but we haven't had the time to go ahead and test those. We believe that you can build your application just fine this way, but you need to run it to do full testing, to make sure it's compatible. Therefore, you're going to have to have access to an x86 machine.

Our strong recommendation at this point is: compile and test for PowerPC on PowerPC systems; Compile and test for x86 systems on actual x86's. That's our suggestion at this point in time. Can you go ahead and use the cross-compilers, which we don't ship it on the OS automatically. Those come with the full BeIDE tools. Until we've done further testing and further work, we recommend you keep the platforms separately. Use the same code base, but build on the appropriate platforms because we know that works.

Lastly, I'm going to talk about crossplatform makefiles. I went ahead and built some crossplatform makefiles. What these are, I don't have a sample to show you, unfortunately, but I have the links if you want to take them down. These are project-like makefiles where at the top you can go ahead and name the application you're building, whether it's an actual application, shared library, and what files it needs, what include paths it needs, what libraries it needs to link against, what resources you want to plug into it.

All of these are platform independent so, for example, if you want to link against libbe, you would go ahead and list libbe.so. The rest of the makefile will go ahead and handle all of the crossplatform information. It will determine what machine you're running on and will choose the appropriate linker. It will choose the appropriate extention for libraries, if you need it. The two I have available are one which supports R3 x86 and PR2 PowerPC binaries. I have another one which will go on -- probably Monday I'll finish it and it will go with the newsletter article on Wednesday which is simplified and will handle the R3 x86 and PowerPC binaries.

That makefile is used for all of those sample_code projects. When the PowerPC version comes out, that will have the updated one that handles both PowerPC and R3 x86. We will continue using them. It won't just be writing them, good luck, have fun with them.

In the future, for example, if we were to adopt other platforms, we would continue making these makefiles handle all that.

Project files move pretty easily from one to another. You have to change what libraries to link to. You can go ahead and continue using project files. But a lot of people are used to makefiles like that. So we wanted to go ahead and make these available without your having to do all the work.

So in general, some final comments before opening it up for Q and A. We strongly recommend people build for both flavors of the BeOS, not just for x86. We want people to write applications for the operating system, wherever that operating system is going to be run. It might mean extra work for people, or people getting extra machines that might not want to do the work. If necessary, work with other developers to make sure both versions of your application are available. We strongly feel that way.

We do have some incompatibles we're working to get around. We've tried to make it as easy as possible for you guys to move where you want to go with the least amount of effort.

Again, just a reminder, the Approaching Crossplatform OS in the Approaching Track session is essentially this talk. Don't go to it. Go to the other. It will be a little more exciting. And thanks a lot for coming. And I'm ready to take questions, if you guys have them. Yes?

A Speaker: Along your lines of your crossplatform makefile there, I know that the MacOS version of CodeWarrior supports multitarget project files. Will that be available in the next release, or are we looking one release after that?

Stephen Beaulieu: My understanding is the version of the BeIDE that Be now is responsible for, it was based off an earlier version than the current MacOS version, so my understanding is that version does not support multiple projects and multiple targets when within a single project, or supports some projects within, that's not the version. It's essentially what you're used to with some improvements and you can choose to make a project either build x86 or PowerPC from both sides if you added the full version and you bring the libraries over from the PowerPC side, for example, on Intel, and you can do that, but the support in the IDE doesn't inclue multiple target support.

A Speaker: Will you consider it?

Stephen Beaulieu: Will we consider it? Probably we'll consider it. It's so early in this new relationship, we haven't even gotten a code yet. We haven't sorted out engineers or exactly what we want to do with it yet. It's just really early in this new phase of our relationship of Metrowerks to know what is going to happen there. Go ahead and you could write me and have a question. I'm sure it will show up in a newsletter article at some point in time as we get more of a path where we're going to go.

A Speaker: Thank you.

Stephen Beaulieu: Next?

A Speaker: The high level for Intel?

Stephen Beaulieu: The what?

A Speaker: Debugging.

Stephen Beaulieu: Debugging. Right. Currently as part of the deal with Metrowerks, we got the PowerPC debugger. Metrowerks did not at this point in time work on an Intel higher level debugger. Trust us. We know this is important. Currently right now we don't have a debugger and I guess I should put that in my slide. Thanks very much for bringing that forward. I had forgotten about that. Currently you need essentially use the terminal debugger or you need to play with your friend printf)_. That's what we do internally in the system as we move forward with the -- excuse me?

A Speaker: Debugger?

Stephen Beaulieu: Yes. As we move forward and get engineers in place to continue our support, I'm sure one of the things that will be coming up is, in addition to we got the debugger and the PowerPC along with it, that we will be doing something with that. I imagine we will also do something with that on the x86 side. It's very important we have a source level debugger. Again, it's new to us right now and it's just going to take some time before we get all of that into place. We don't know what path we're going to take to handle that. But it is important to us and we will be doing it.

Yes?

A Speaker: How are we going to handle these file system issues? For users obviously it's going to be much more important, with a floppy or Zip disk.

Stephen Beaulieu: Two things with that. One on x86, we support floppies, but things like Zip diska won't work right now. So that is an important issue we need to get up with. In addition, what needs to be written is a tool that will read opposite endian BFS. It's possible that a third party could work up something in the meantime by talking with our kernel team about the structure and swapping that information so they can see it. Maybe, maybe not. I'm not really sure what goes on with that. But it is important to us. And again, it's something we just couldn't get done in time. Our goal right now is to finish up the PowerPC version of R3, and get that out next month, and from then we're going to look at what's supposed to be coming. It's high on the list of things to do.

Again, we like to think of the operating system as multiplatform where you can take the file system from one and move it into the other. Obviously, you couldn't access applications because of the binary format, but just getting at the data, we understand it's important, and yes, we are working on it. I can't commit to when it's going to be done.

A Speaker: Stephen, you might want to mention Tar floppies.

Stephen Beaulieu: Right. You can Tar floppies. You can move a floppy, Tar it up. You can take that Tar file as if you FTP it. Currently, right now, the best way to do it is use the network. You've got FTP, an FTP server on both systems. Go ahead and put them up via Internet locally and pass them back and forth and your data will be fine. But in the long run, we are going to have the support. I just can't say when.

A Speaker: Why is it necessary to have the Be file system mirror your host's endian format?

Stephen Beaulieu: I don't know exactly why they did that. One, yeah there is going to be a lot of performance issues involved with that. If on -- say you're running x86, and it had to write Big-endian all the time, it would be constantly swapping that out every time it did an active, every time it looked at the file system, here it is. You would get --

A Speaker: Wouldn't that be a hardware thing?

A Speaker: Well, the problem is you have to do it into the block cache so it would actually have to do with when going to memory, so it's not like the disk access would be slow enough to mask the swapping. It would need a measurable slowdown and file system throughput. So since that is good with BeOS, we can do that.

Stephen Beaulieu: Again, most of the time in the system, you're not going to be mounting an opposite endian system on there. You need a tool that will handle swapping and reading and writing and understanding the format. It's doable. We're going to be doing it. But, again, it's just not done now.

A Speaker: Is this just a problem that's a string move I write on the disk I have to swap?

Stephen Beaulieu: No. You don't have to swap anything. Basically the file system uses a bunch of ints to keep track of how long something is, what node is associated with it. That's all internal with the file structure. Your content itself is just content. That is compatible. That works. The problem is if you have something formatted with data, with the information from keeping track of what data is there, that's all internal to the bfs. It's that information that is of a different endian order because of the memory system internally. It's only when you try to take one of those hard disks or floppy or Zip and moved it to an endian platform --

A Speaker: So a quicktime movie is fine?

Stephen Beaulieu: Right. That's the content. The content is the same. It's just the structure that identifies what the content is. That's what's currently incompatible. That needs a tool that understands on a Big-endian system how to read Little-endian BFS. It needs to identify where that data is. That's what needs to change.

Any other questions? Comments? Complaints?

A Speaker: Is there a release schedule right now for any new compilers?

Stephen Beaulieu: Let me go ahead and step back. As far as I know, internally, we're looking at the potential to have other compilers or C and C++ BeOS applications. Right now there's the Metrowerks compiler. You can also get the gcc compiler that will build C objects. Now, these objects can then be linked into the Metrowerks linker. The problem we have right now is for other compiler support, bringing something over, or on the PowerPC side if Motorola wanted to port their compiler. Dealing with the C++ classes, each compiler and linker has got its own vtable format, its own method of handling exceptions. Those need to be kept in sync. Internally we go ahead and -- Jon wants to say something? It looked like you opened your mouth to say something. He's more of an expert on this area than I am.

So basically that would need to happen for future compilers: on PPC, Metrowerks is the premier compiler. It's the most widely used for MacOS. As we move to Intel, x86 there are a lot of other compilers out there: VisualC++ from Microsoft, other compilers like Borland, or the Intel reference compiler. There are just a bunch of things like that. It's more likely because there are other compilers that support the file formats that we will get in the future some that will port the compiler so the BeOS stuff will work. At that point in time, some of the things we've talked about in terms of importing and exporting symbols becomes important. You can use #pragma exporting now, it works like a charm, but it's not guaranteed to work on, say, other compilers. We're trying to preempt the fact we are expecting at some time in the future to have additional compiler support. You take the projects, you're building them now, and do it in a way that's going to be supported more likely in the future.

I saw Bruce?

A Speaker: Yes, you mentioned that the __declspec will work on PowerPC and the Intel compiler, but which version of the compiler? I don't think the __declspec will work on the compiler I'm working with right now.

Stephen Beaulieu: On the PowerPC side, the final version of the Metrowerks one -- that will ship when R3 for PowerPC ships -- does support declspec. Brian Stern has assured me of that. And it's just a matter of getting the right version in to support it. He's been using it and it's been assured that is going to work, which is why we are telling you it's working, and if for some reason it doesn't work, we're going to hold Metrowerks to the fact they told us it needs to work. If you have one with a beta, it might not work on that. But I will assure you in the final version it does and will. They have been using it internally.

Brian also told me there are occasionally some problems. You need to make sure you declare things in the right order. If you had problems in your header files sometimes, declspec will get confused with that and some things won't work. So if you have been running into those problems, talk to me.

A Speaker: We actually ran into the problem with the #pragma export on the Intel side.

Stephen Beaulieu: #pragma export?

A Speaker: Well, I may not have been using it the way it was intended to be used.

Stephen Beaulieu: So #pragma export wasn't working for you on Intel?

A Speaker: Yeah. It looks like it's trying to link temporaries or something like that.

Stephen Beaulieu: What you're probably running into when you do exporting and importing of symbols, it has to be the first time the symbol is run across. So you can wrap the #pragma export around the code section. But if that symbol, for example, is mentioned in a header file somewhere, the first time it stumbles across the header file, it will say, "Oh, I'm not importing or exporting." That's a problem with the way Intel works. That's why we suggest people have a forward declaration header that list all of the globals they want to import and export there, and have that be the first thing included and the first time.

A Speaker: Two questions.

Stephen Beaulieu: Yes?

A Speaker: Two questions. On the declspec stuff, if you have an entire class of which some functions are to be exported are exported, but not all, the #pragma, an equivalent of declspec --

Stephen Beaulieu: Is the class exported?

A Speaker: My class. It has member functions A, B, C, D, E and F.

Stephen Beaulieu: Uh-huh.

A Speaker: And B and C are considered part of public API.

Stephen Beaulieu: Is the class considered part of the public API? Then export the class and C++ will take care of whether the symbols are public or not.

A Speaker: The real question was PowerPC users are very aware of Intel chips. Intel users are very unaware of anything else existing.

Stephen Beaulieu: Yes.

A Speaker: So I'm curious if you know of any policy or thoughts at Be in making sure that Intel users don't come along and compile this stuff for Intel and say, "You know, it's just debugging time to compile and debug for PowerPC." One of the possibilities -- I'm sorry. One of the possibilities that occurred to me you guys might have a policy that anything that occurs on your FTP site has to be compiled in both platforms.

Stephen Beaulieu: I do not know --

A Speaker: Can you repeat the question?

Stephen Beaulieu: Basically the concern was there were a good number of PowerPC developers for BeOS who are aware, of course, of Intel machines and Intel processors and will probably go ahead and buy Intel machines, and therefore will build for both. There's likely to be a lot of brand-new Intel-only BeOS developers who might not have access to PowerPC machines, or because it's such a small segment, might not want to build their applications for PowerPC, and what sort of policies will Be have about, say, on the BeWare site or FTP site, making sure if you upload something, you include both a PowerPC and x86 version.

Officially, I do not think we have decided on a position. I do not know if the BeWare rules will change, will require that you have both. We are definitely going to strongly encourage people to do both. We want people to team up with other developers to, if necessary, and they can't get on a PowerPC machine, team up with other developers so those other developers with access to PowerPC can build them.

We encourage people to come to the Be offices where we have PowerPC machines and come in and compile, you know, make arrangements with us to compile and do some testing so it can be available. We feel very strongly that we are one OS, not -- we're one OS, but an OS with two flavors. One flavor is necessarily not more important than the other. We want on both sides. Is it likely some of these Intel developers aren't going to care and will set up their own Web sites? Unfortunately, that's likely to be the reality and likely to become more important as we don't have support for the new PowerPC machines as Apple hasn't given us the information we need to support them.

So the PowerPC machines that run the BeOS are a year old now. A year from now if we don't get more information from Apple, they'll be two years old. We do not want PowerPC to be marginal. As a company, is that something we can absolutely prevent? Maybe not. Is it something we can try to prevent, yes, but just not an easy answer.

Yes, in the back?

A Speaker: Are there plans for crosscompilers to handle this issue?

Stephen Beaulieu: There are crosscompilers available, but you still have to have the other flavor of machine to actually do the testing. So yes, one solution for this would be to have the people crosscompile and basically put it up on the Web site and say, "If you have a PowerPC BeOS machine, download it, run it, and tell me what happens. Here are XAPs. When I crash, tell me what function I crash in." We would much prefer something like that to happen and have developers work together to make sure it works that way than for all of the Intel developers to say, "I don't care about it."

A Speaker: If it happens to work, be sure to send in your registration.

Stephen Beaulieu: Yes. So that's hopefully the way we're going to go about it. We might come up with some official policies. I don't know.

Yes?

A Speaker: Will there be an emulator for Mac, for BeOS for Intel, like dropping on VirtualPC?

Stephen Beaulieu: BeOS for Intel working on an emulator for Mac like VirtualPC? Probably not.

A Speaker: It's not a design rule.

Stephen Beaulieu: Definitely not something we're paying attention to. If it works, its performance is probably going to suck. We heartily recommend if you have a PowerPC and you can run a virtual PC emulator on it, BeOS running on that PC emulator is going to be a lot slower than just plain getting the PowerPC version yourself. The same thing if there are to be a PowerPC emulator on x86 side, just run the version that works on your machine.

Yes?

A Speaker: For that matter, it won't even install on virtual PC.

Stephen Beaulieu: Well, there you go.

A Speaker: imagesly because of the selection of hardware virtual PC emulates.

Stephen Beaulieu: It's possible as we get more support -- I'll go ahead and quit this thing. We've got five minutes before the next session starts. We're supposed to be done?